public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* JvSynchronize nitpick
@ 2000-03-27 18:24 Paul Fisher
  2000-03-27 19:05 ` Tom Tromey
  2000-04-01  0:00 ` Paul Fisher
  0 siblings, 2 replies; 16+ messages in thread
From: Paul Fisher @ 2000-03-27 18:24 UTC (permalink / raw)
  To: java-discuss

For JvSynchronize, why not make `synchronized' a macro (or slightly
name mangled) that expands into the current JvSynchronize syntax?

So C++ code would look like:

{ synchronized (OBJ); CODE; }

which is more in line with the Java syntax.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: JvSynchronize nitpick
  2000-03-27 18:24 JvSynchronize nitpick Paul Fisher
@ 2000-03-27 19:05 ` Tom Tromey
  2000-03-27 21:54   ` Paul Fisher
  2000-04-01  0:00   ` Tom Tromey
  2000-04-01  0:00 ` Paul Fisher
  1 sibling, 2 replies; 16+ messages in thread
From: Tom Tromey @ 2000-03-27 19:05 UTC (permalink / raw)
  To: Paul Fisher; +Cc: java-discuss

>>>>> "Paul" == Paul Fisher <pnfisher@redhat.com> writes:

Paul> For JvSynchronize, why not make `synchronized' a macro (or
Paul> slightly name mangled) that expands into the current
Paul> JvSynchronize syntax?

I don't know.  It was this way when I started working on it.
One problem is choosing a variable name.

Paul> So C++ code would look like:
Paul> { synchronized (OBJ); CODE; }
Paul> which is more in line with the Java syntax.

We could even play some trick using "for" and a helper object to let
us write code like this:

    synchronized (foo)
      {
       ...
      }


(untested, with poor names)

   class helper
   {
	JvSynchronize sync;
	int count;
	helper(obj) : sync (obj), count (0) { }
	operator bool () { return count == 0; }
	helper &operator++ () { ++count; return *this; }
   }

   #define synchronized(Object) for (helper x (Object); ! x; ++x)

That might be too magical, not to mention slow.

Tom

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: JvSynchronize nitpick
  2000-03-27 19:05 ` Tom Tromey
@ 2000-03-27 21:54   ` Paul Fisher
  2000-03-28 17:34     ` Alexandre Oliva
  2000-04-01  0:00     ` Paul Fisher
  2000-04-01  0:00   ` Tom Tromey
  1 sibling, 2 replies; 16+ messages in thread
From: Paul Fisher @ 2000-03-27 21:54 UTC (permalink / raw)
  To: java-discuss

Tom Tromey <tromey@cygnus.com> writes:

> That might be too magical, not to mention slow.

I'm rather fond of that magic.  How about something a bit simpler?

class JvSynchronizeHelper
{
  JvSynchronize sync;
public:
  bool done;
  JvSynchronizeHelper (const jobject &obj) : sync (obj), done (false) { }
};

#define synchronized(OBJECT) \
  for (JvSynchronizeHelper JvX (OBJECT); !JvX.done; JvX.done = true)

Of course, this could wreak havoc if a `break' or a `continue' were to
occur inside of a synchronized block contained within an iterative
construct.  For that situation, one could always fall back to using
JvSynchronize, but would that be too confusing?

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: JvSynchronize nitpick
  2000-03-27 21:54   ` Paul Fisher
@ 2000-03-28 17:34     ` Alexandre Oliva
  2000-03-28 20:28       ` Paul Fisher
  2000-04-01  0:00       ` Alexandre Oliva
  2000-04-01  0:00     ` Paul Fisher
  1 sibling, 2 replies; 16+ messages in thread
From: Alexandre Oliva @ 2000-03-28 17:34 UTC (permalink / raw)
  To: java-discuss

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

How about:

class JvSynchronizeHelper
{
  JvSynchronize sync;
public:
  JvSynchronizeHelper (const jobject &obj) : sync (obj) {}
  operator bool () const { return false; }
};

#define synchronized(OBJECT) \
  if (const JvSynchronizeHelper& __JvX = JvSynchronizeHelper((OBJECT))) \
    ; \
  else

Or, even better: can't JvSynchronize have an implicit converter to
bool false?

-- 
Alexandre Oliva    Enjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company        aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist    CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org}   Write to mailing lists, not to me

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: JvSynchronize nitpick
  2000-03-28 17:34     ` Alexandre Oliva
@ 2000-03-28 20:28       ` Paul Fisher
  2000-03-28 20:47         ` Per Bothner
  2000-04-01  0:00         ` Paul Fisher
  2000-04-01  0:00       ` Alexandre Oliva
  1 sibling, 2 replies; 16+ messages in thread
From: Paul Fisher @ 2000-03-28 20:28 UTC (permalink / raw)
  To: java-discuss

Alexandre Oliva <aoliva@cygnus.com> writes:

> Or, even better: can't JvSynchronize have an implicit converter to
> bool false?

Is there any reason why we can't go ahead and add this?  It seems like
a perfect solution.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: JvSynchronize nitpick
  2000-03-28 20:28       ` Paul Fisher
@ 2000-03-28 20:47         ` Per Bothner
  2000-03-28 21:33           ` Paul Fisher
  2000-04-01  0:00           ` Per Bothner
  2000-04-01  0:00         ` Paul Fisher
  1 sibling, 2 replies; 16+ messages in thread
From: Per Bothner @ 2000-03-28 20:47 UTC (permalink / raw)
  To: java-discuss

Paul Fisher <pnfisher@redhat.com> writes:

> Is there any reason why we can't go ahead and add this?  It seems like
> a perfect solution.

It's a ok solution to a non-problem, I feel.
The only real problem I see with the existing JvSynchronized
helper class is the need to specify a dummy variable name.

I'm not sure I like adding a `synchronized' macro: macros are to be
avoided in C++, because they violate the other name-scoping rules.
Especially, a name like `synchronized', which might easily conflict
with other head files.  Still, if we want to avoid having to name a
dummy variable, we need to use a macro.  However. I think it should
be something following the Jv-prefix convention.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: JvSynchronize nitpick
  2000-03-28 20:47         ` Per Bothner
@ 2000-03-28 21:33           ` Paul Fisher
  2000-03-29  8:27             ` Per Bothner
  2000-04-01  0:00             ` Paul Fisher
  2000-04-01  0:00           ` Per Bothner
  1 sibling, 2 replies; 16+ messages in thread
From: Paul Fisher @ 2000-03-28 21:33 UTC (permalink / raw)
  To: java-discuss

Per Bothner <per@bothner.com> writes:

> It's a ok solution to a non-problem, I feel.

CNI allows for a near seamless transition when switching between
writing Java and C++ code.  The more seamless we can make that
transition, the better.

For instance, we add a length attribute and overload [] for arrays in
CNI.  Why not allow the same natural Java construct for `synchronized'
to be used in C++?

We could simply say that `synchronized' is a reserved word when
writing CNI, just as it is when writing Java.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: JvSynchronize nitpick
  2000-03-28 21:33           ` Paul Fisher
@ 2000-03-29  8:27             ` Per Bothner
  2000-04-01  0:00               ` Per Bothner
  2000-04-01  0:00             ` Paul Fisher
  1 sibling, 1 reply; 16+ messages in thread
From: Per Bothner @ 2000-03-29  8:27 UTC (permalink / raw)
  To: java-discuss

Paul Fisher <pnfisher@redhat.com> writes:

> CNI allows for a near seamless transition when switching between
> writing Java and C++ code.  The more seamless we can make that
> transition, the better.

The goal of CNI is seamless access to Java objects and methods
from C++, using *C++ syntax*.  The goal is not to make C++ look like Java.

> For instance, we add a length attribute and overload [] for arrays in
> CNI.  Why not allow the same natural Java construct for `synchronized'
> to be used in C++?

I don't understand where the "same natural Java construct" comes in.
Overloading operator[] is a standard C++ idiom, while
using a dummy object with a finalizer is the standard C++ idiom
for `try'-`finally', of which `synchronized' is a special case.

> We could simply say that `synchronized' is a reserved word when
> writing CNI, just as it is when writing Java.

We could, but I don't see why it would be a good idea.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: JvSynchronize nitpick
  2000-03-28 17:34     ` Alexandre Oliva
  2000-03-28 20:28       ` Paul Fisher
@ 2000-04-01  0:00       ` Alexandre Oliva
  1 sibling, 0 replies; 16+ messages in thread
From: Alexandre Oliva @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

How about:

class JvSynchronizeHelper
{
  JvSynchronize sync;
public:
  JvSynchronizeHelper (const jobject &obj) : sync (obj) {}
  operator bool () const { return false; }
};

#define synchronized(OBJECT) \
  if (const JvSynchronizeHelper& __JvX = JvSynchronizeHelper((OBJECT))) \
    ; \
  else

Or, even better: can't JvSynchronize have an implicit converter to
bool false?

-- 
Alexandre Oliva    Enjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company        aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist    CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org}   Write to mailing lists, not to me

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: JvSynchronize nitpick
  2000-03-28 20:28       ` Paul Fisher
  2000-03-28 20:47         ` Per Bothner
@ 2000-04-01  0:00         ` Paul Fisher
  1 sibling, 0 replies; 16+ messages in thread
From: Paul Fisher @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Alexandre Oliva <aoliva@cygnus.com> writes:

> Or, even better: can't JvSynchronize have an implicit converter to
> bool false?

Is there any reason why we can't go ahead and add this?  It seems like
a perfect solution.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* JvSynchronize nitpick
  2000-03-27 18:24 JvSynchronize nitpick Paul Fisher
  2000-03-27 19:05 ` Tom Tromey
@ 2000-04-01  0:00 ` Paul Fisher
  1 sibling, 0 replies; 16+ messages in thread
From: Paul Fisher @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

For JvSynchronize, why not make `synchronized' a macro (or slightly
name mangled) that expands into the current JvSynchronize syntax?

So C++ code would look like:

{ synchronized (OBJ); CODE; }

which is more in line with the Java syntax.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: JvSynchronize nitpick
  2000-03-28 21:33           ` Paul Fisher
  2000-03-29  8:27             ` Per Bothner
@ 2000-04-01  0:00             ` Paul Fisher
  1 sibling, 0 replies; 16+ messages in thread
From: Paul Fisher @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Per Bothner <per@bothner.com> writes:

> It's a ok solution to a non-problem, I feel.

CNI allows for a near seamless transition when switching between
writing Java and C++ code.  The more seamless we can make that
transition, the better.

For instance, we add a length attribute and overload [] for arrays in
CNI.  Why not allow the same natural Java construct for `synchronized'
to be used in C++?

We could simply say that `synchronized' is a reserved word when
writing CNI, just as it is when writing Java.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: JvSynchronize nitpick
  2000-03-27 19:05 ` Tom Tromey
  2000-03-27 21:54   ` Paul Fisher
@ 2000-04-01  0:00   ` Tom Tromey
  1 sibling, 0 replies; 16+ messages in thread
From: Tom Tromey @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Paul Fisher; +Cc: java-discuss

>>>>> "Paul" == Paul Fisher <pnfisher@redhat.com> writes:

Paul> For JvSynchronize, why not make `synchronized' a macro (or
Paul> slightly name mangled) that expands into the current
Paul> JvSynchronize syntax?

I don't know.  It was this way when I started working on it.
One problem is choosing a variable name.

Paul> So C++ code would look like:
Paul> { synchronized (OBJ); CODE; }
Paul> which is more in line with the Java syntax.

We could even play some trick using "for" and a helper object to let
us write code like this:

    synchronized (foo)
      {
       ...
      }


(untested, with poor names)

   class helper
   {
	JvSynchronize sync;
	int count;
	helper(obj) : sync (obj), count (0) { }
	operator bool () { return count == 0; }
	helper &operator++ () { ++count; return *this; }
   }

   #define synchronized(Object) for (helper x (Object); ! x; ++x)

That might be too magical, not to mention slow.

Tom

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: JvSynchronize nitpick
  2000-03-28 20:47         ` Per Bothner
  2000-03-28 21:33           ` Paul Fisher
@ 2000-04-01  0:00           ` Per Bothner
  1 sibling, 0 replies; 16+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Paul Fisher <pnfisher@redhat.com> writes:

> Is there any reason why we can't go ahead and add this?  It seems like
> a perfect solution.

It's a ok solution to a non-problem, I feel.
The only real problem I see with the existing JvSynchronized
helper class is the need to specify a dummy variable name.

I'm not sure I like adding a `synchronized' macro: macros are to be
avoided in C++, because they violate the other name-scoping rules.
Especially, a name like `synchronized', which might easily conflict
with other head files.  Still, if we want to avoid having to name a
dummy variable, we need to use a macro.  However. I think it should
be something following the Jv-prefix convention.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: JvSynchronize nitpick
  2000-03-27 21:54   ` Paul Fisher
  2000-03-28 17:34     ` Alexandre Oliva
@ 2000-04-01  0:00     ` Paul Fisher
  1 sibling, 0 replies; 16+ messages in thread
From: Paul Fisher @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Tom Tromey <tromey@cygnus.com> writes:

> That might be too magical, not to mention slow.

I'm rather fond of that magic.  How about something a bit simpler?

class JvSynchronizeHelper
{
  JvSynchronize sync;
public:
  bool done;
  JvSynchronizeHelper (const jobject &obj) : sync (obj), done (false) { }
};

#define synchronized(OBJECT) \
  for (JvSynchronizeHelper JvX (OBJECT); !JvX.done; JvX.done = true)

Of course, this could wreak havoc if a `break' or a `continue' were to
occur inside of a synchronized block contained within an iterative
construct.  For that situation, one could always fall back to using
JvSynchronize, but would that be too confusing?

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: JvSynchronize nitpick
  2000-03-29  8:27             ` Per Bothner
@ 2000-04-01  0:00               ` Per Bothner
  0 siblings, 0 replies; 16+ messages in thread
From: Per Bothner @ 2000-04-01  0:00 UTC (permalink / raw)
  To: java-discuss

Paul Fisher <pnfisher@redhat.com> writes:

> CNI allows for a near seamless transition when switching between
> writing Java and C++ code.  The more seamless we can make that
> transition, the better.

The goal of CNI is seamless access to Java objects and methods
from C++, using *C++ syntax*.  The goal is not to make C++ look like Java.

> For instance, we add a length attribute and overload [] for arrays in
> CNI.  Why not allow the same natural Java construct for `synchronized'
> to be used in C++?

I don't understand where the "same natural Java construct" comes in.
Overloading operator[] is a standard C++ idiom, while
using a dummy object with a finalizer is the standard C++ idiom
for `try'-`finally', of which `synchronized' is a special case.

> We could simply say that `synchronized' is a reserved word when
> writing CNI, just as it is when writing Java.

We could, but I don't see why it would be a good idea.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2000-04-01  0:00 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-03-27 18:24 JvSynchronize nitpick Paul Fisher
2000-03-27 19:05 ` Tom Tromey
2000-03-27 21:54   ` Paul Fisher
2000-03-28 17:34     ` Alexandre Oliva
2000-03-28 20:28       ` Paul Fisher
2000-03-28 20:47         ` Per Bothner
2000-03-28 21:33           ` Paul Fisher
2000-03-29  8:27             ` Per Bothner
2000-04-01  0:00               ` Per Bothner
2000-04-01  0:00             ` Paul Fisher
2000-04-01  0:00           ` Per Bothner
2000-04-01  0:00         ` Paul Fisher
2000-04-01  0:00       ` Alexandre Oliva
2000-04-01  0:00     ` Paul Fisher
2000-04-01  0:00   ` Tom Tromey
2000-04-01  0:00 ` Paul Fisher

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).