gamedevlists-general — List for discussing general game development issues

[GD-General] Java bitching

[Brian H. <bri...@py...>]

Not nearly as well reasoned as Ian Joyner's treatise on C++, but I
thought some of you might find it interesting.  The things in it that I
do understand I don't think I necessarily agree with, however since I'm
not a Java expert, I don't have a position on the other stuff:

http://www.jwz.org/doc/java.html

Brian

Re: C++ multiple inheritance [was Re: [GD-General] Eiffel]

[Thatcher U. <tu...@tu...>]

On Jan 02, 2002 at 11:28 -0800, Jesse Jones wrote:
> >I realize that you're advocating a hierarchy that looks like this:
> >
> >B
> >|
> >C D A
> >  \|/
> >   E
> >
> >But I don't think there's a good way to enforce that.
> 
> Nope, and even if you're careful and rigorously distinguish between 
> main-line and mixin classes it's still possible to accidentally mix 
> in the same class twice into an inheritance hierarchy. However in 
> practice I haven't found this too be much of a problem and this 
> approach neatly sidesteps all of the subtleties and ugliness 
> associated with virtual inheritance.

My point is, *always* using virtual inheritance is the only way to
make MI truly safe.  Then the subtleties and ugliness are all in the
compiler (where they belong).  You (and Meyers for that matter) have
this backwards -- the "diamond of death" is actually what you want in
all the class hierarchies I've come across.  If you find yourself
wanting non-virtual inheritance, it means you're trying to model a
kind of "is-implemented-in-terms-of", which should not be done with
inheritance at all.  Non-virtual multiple inheritance is a bug in C++.

IMHO, of course :)

-- 
Thatcher Ulrich <tu...@tu...>
http://tulrich.com

[GD-General] RE: Preprocessors

[Jesse J. <jes...@mi...>]

At 12:20 PM -0800 1/2/02, Steve Rabin wrote:
>  > Or the belief that languages shouldn't have preprocessors because the
>>  C preprocessor was so gross; inevitably you lose major functionality
>>  like "#ifdef 0/#endif" and the language designers defend it to the
>>  end.
>
>I'm glad to see people acknowledging that the C preprocessor is a 
>powerful tool and not something to be shunned unconditionally. Used 
>improperly, you can cut off your own leg, but the same is true for a 
>chainsaw - yet both are still useful tools.
>
>I'm so sick of hearing over and over again about the evils of 
>preprocessors that I'm writing an article for Game Programming Gems 
>3 on "Finding Redeeming Value in C-Style Macros." Since the article 
>is still in-progress, I was wondering if I could pick the brains of 
>the people on this list... Currently, I have about eight pretty good 
>macro tricks, but I'm open to adding more.

If you haven't seen it already, you should also check out the boost 
preprocessor library (see 
<http://www.boost.org/libs/preprocessor/doc/index.htm>). It's a 
rather extensive library for preprocessor programming.

   -- Jesse

RE: [GD-General] Eiffel

[Matt D. <ma...@co...>]

On many laptops you can set it up so that on shutting the lid, Windows 2000
(if you're running it) will go straight into hibernate mode.  What this
means is that it dumps the complete memory contents to harddisk and shuts
down.  On booting up it just loads back in the memory dump and asks you for
your password.  Word of warning - don't use it if you plan to change your
hardware configuration.

While we on the subject, can you get Linux to do the same?  E-mail me
privately please as I'm entering the realms of OT.  I, for one, do not like
leaving my machine on.

Cheers!


Matt Davies
Programmer, Confounding Factor
ma...@co...
www.confounding-factor.com



-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Jamie Fowlston
Sent: 02 January 2002 17:22
To: gam...@li...
Subject: RE: [GD-General] Eiffel


Aha! Never knew about that one. Ta. Shall see how well it works :)

Jamie


-----Original Message-----
From: Matt Davies [mailto:ma...@co...]
Sent: 02 January 2002 17:19
To: Jamie Fowlston; gam...@li...
Subject: RE: [GD-General] Eiffel


You can, sort of, with Windows 2000 by using the Hibernate shutdown option.
Wished Linux had that.


Matt Davies
Programmer, Confounding Factor
ma...@co...
www.confounding-factor.com




-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Jamie Fowlston
Sent: 02 January 2002 14:56
To: gam...@li...
Subject: RE: [GD-General] Eiffel


<Snip>
ObNote: My work system is inherently built on the assumption that my
systems will have uptimes measured in months.  As such I can
establish and preserve such "work contexts" for extended periods,
building and maintaining their value.  Typically I log into my
desktop once and then don't log back out again until I install a new
kernel (once or twice a year).
</Snip>

Although it would be nice to have a system where such things are persistent
regardless of whether or not you leave the machine on.

Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of J
C Lawrence
Sent: 24 December 2001 20:29
To: ph...@me...
Cc: gam...@li...
Subject: Re: [GD-General] Eiffel


On Mon, 24 Dec 2001 11:50:26 -0000
Philip Harris <ph...@me...> wrote:

> I can see why that would cause problems under windows although I
> would guess that your multiple Emacs frames would be one window
> with a lot of children on Windows.

Ahh, MDI.  <retch>

I tend to run windows in terms of contexts.  A virtual desktop will
have a number of windows on it, all applying or related to a given
task.  Typically this will mean a few XEMacs frames, a few xterms, a
few browser windows, etc.  Then repeat that on the next desktop for
the next task (more accurately "frame of mind").

Sometimes its system based.  Currently I have a desktop devoted to
some IPSec work I'm doing on Alice (system name), another devoted to
some InterMezzo stuff going on on Koala, a desktop for root sessions
on various machines (grouped for security reminders), one devoted to
some work stuff I'm doing locally on a protocol stack, another for a
private PHP project, etc

> It's interesting (at least to me) that you find that sort of
> environment so efficient.

I got used to it -- started with the approach roughly 14 years ago
and have never looked back.

> I tend to work the opposite way, the less windows, files and apps
> open at any one time the quicker things move along. Perhaps it's
> Windows imposing its will on me...

At any given time I'll tend to work only on a small subset.  But
then I change subsets fairly regularly.  It might take me several
days, occasionally more than a month, to get back to any particular
context set (private projects particularly tend to suffer such long
gaps), but when I do everything is still there ready and waiting in
the exact same relationship, with the exact same XEmacs edit history
and internal context etc as it had the instant I stopped working on
it -- easy for the mental gears to click back into and start up
again.

ObNote: My work system is inherently built on the assumption that my
systems will have uptimes measured in months.  As such I can
establish and preserve such "work contexts" for extended periods,
building and maintaining their value.  Typically I log into my
desktop once and then don't log back out again until I install a new
kernel (once or twice a year).

  Yeah, its Linux, so I tend to follow the hectic kernel upgrade
  path.  I'd rather do upgrades, and thus reboots, every other year,
  but there are always too many interesting things depending on some
  new kernel rev to tempt me away to upgrading.

> Obviously your approach works very well for you. Do you know of
> other people who work the same way?

I know of a few (perhaps a half dozen), not that many.  Of course a
few of them have copied from me -- usually after having copied my
FVWM RC (which seems to be a viral meme in its own right).

> Is it an apporach you've been using a long time or it still
> evolving?

At the low level it evolves constantly as I adopt new tools and
changes smaller practices.  As you can see from the screenshots
directory I posted a while back, its wasn't that long ago I finally
decided that icons were evil and evicted them from my system.
Similarly I recently moved from Netscape to Galeon (a Gecko based
browser which supports a number of useful UI features such as being
able to restart with all the same windows open and all the same
pages loaded as it had when it was brought down).

My browsing habits haven't changed in detail.  I still follow the
same pattern of reading a page and opening a new window (or TAB in
Galeon's case) on every interesting link as I go along (I almost
never use the forward/back buttons), but now I tend to group pages
in Galeon Windows on a task, character, and interest basis.  As such
I have a Galeon window each containing multiple TABs devoted only to
pages which will require long term study research (typically online
books), another to firewall research, another to IPSec, another to
MUD-Dev, another to blogs, another to performance metrics, another
to Kanga.Nu, another to temp/trash stuff...etc.

> I'm just interested because that sort of approach doesn't seem
> efficient to me at all.

I suspect our work methods are not that different within a single
given project.  In any given contenxt I usually have little going on
(a couple XEmacs frames, a few xterms, a browser or two, a couple
supporting apps, and that's about it).  The likely difference is
that I maintain state and context for many projects and sub-projects
as I go along, that I expect to keep them (and do) for variously
long periods, that I fork such contexts regularly, and that I pop
among them easily.

  I get a lot of startled looks from passersby.

The ticket is not trying to work with them all at once, but building
and storing work contexts such that they're easily context shiftable
among.  Easy support for mental context shifting is the basic
assumption of this work method.

My problem now, and my current big interest in XEMacs UI
development, is seeing how I can shove that same work process down
into editing sessions within XEmacs on a large project.  Too often I
get into a "What is this token and why is it being used quite like
this?" research project, which of course recursively forks as I dig
down into other identical researches on other tokens. I need a way
to tag and lock context frames on those investigations so that I can
later pop back to them, and then usefully pop about among them,
possibly with a matching annotation system.  Barry Warsaw's WinRing
elisp looks very useful as a component for this, but I haven't
settled on a basic approach yet.

--
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general


_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general



_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

Re: C++ multiple inheritance [was Re: [GD-General] Eiffel]

[Jesse J. <jes...@mi...>]

At 11:49 PM -0500 1/2/02, Thatcher Ulrich wrote:
>On Dec 27, 2001 at 03:46 -0800, Jesse Jones wrote:
>>  At 4:56 PM -0500 12/27/01, Thatcher Ulrich wrote:
>  > >On Dec 22, 2001 at 04:30 -0800, Jesse Jones wrote:
>  > I assume you're talking about a smart pointer class that requires
>>  invasive changes to the object it's pointing at. For example, a smart
>>  pointer class that maintains ref counts and requires that the object
>>  have a common reference counted implementation.
>
>Yup, that's what I meant.
>
>>  In general I think it's better to try to come up with a non-invasive
>>  design.
>
>I'm curious to know more; can you explain, or point me at a reference?

For the case above you can put the ref count inside the smart pointer 
class. The only tricky bit is that the smart pointer objects have to 
share the count, but you can handle this by making the first smart 
pointer object instantiated allocate the count on the heap. When a 
smart pointer is copied it copies the ref count ptr and adjusts the 
ref counts. This is a bit slower because of the one extra allocation, 
but it's awfully nice to be able to easily pass around ref-counted 
pointers for arbitrary types.

>  > However I have dealt with problems like this. For example, I used to
>>  have an Invariant class that allowed for DbC-style invariant checks.
>>  The class had a virtual Invariant method and a counter that was
>>  incremented when entering a public method and decremented when
>>  exiting a public method. But mixins still wanted to call the
>>  invariant so what I did was dynamic_cast the mixin this pointer to an
>>  Invariant* and call the Invariant method if the result wasn't NULL.
>
>I've been pondering this.  I think dynamic_cast has a couple of
>problems for this usage.  For one thing, it's slower than a virtual
>base class lookup.

Big deal. As long as you're aware of the overhead and don't do 
anything silly it should be fine.

>I realize that you're advocating a hierarchy that looks like this:
>
>B
>|
>C D A
>  \|/
>   E
>
>But I don't think there's a good way to enforce that.

Nope, and even if you're careful and rigorously distinguish between 
main-line and mixin classes it's still possible to accidentally mix 
in the same class twice into an inheritance hierarchy. However in 
practice I haven't found this too be much of a problem and this 
approach neatly sidesteps all of the subtleties and ugliness 
associated with virtual inheritance.

   -- Jesse

C++ multiple inheritance [was Re: [GD-General] Eiffel]

[Thatcher U. <tu...@tu...>]

On Dec 27, 2001 at 03:46 -0800, Jesse Jones wrote:
> At 4:56 PM -0500 12/27/01, Thatcher Ulrich wrote:
> >On Dec 22, 2001 at 04:30 -0800, Jesse Jones wrote:
> >>
> >>  Unfortunately MI has a bad reputation in C++. Even people who should
> >>  know better like Scot Myers rag on it. But essentially all of the
> >>  problems with MI in C++ are because of virtual base classes. So how
> >>  do you avoid virtual base classes? By avoiding diamond shaped
> >>  inheritance hierarchies.
> >>
> >>  One way to do this is by using mixin classes. You have your main-line
> >>  classes like Widget or Monster or whatever and then you have mixin
> >>  classes like ReferenceCountedMixin or ObserverMixin or whatever.
> >>  Mixins only descend from other mixins so you never wind up with the
> >>  diamond of death.
> >
> >I've been pondering this.  I've always depended on virtual inheritance
> >for effective mixins.  For example, how do you implement smart
> >pointers to mixins of ref-counted classes, without virtual
> >inheritance?
> 
> I assume you're talking about a smart pointer class that requires 
> invasive changes to the object it's pointing at. For example, a smart 
> pointer class that maintains ref counts and requires that the object 
> have a common reference counted implementation.

Yup, that's what I meant.

> In general I think it's better to try to come up with a non-invasive
> design.

I'm curious to know more; can you explain, or point me at a reference?

> However I have dealt with problems like this. For example, I used to 
> have an Invariant class that allowed for DbC-style invariant checks. 
> The class had a virtual Invariant method and a counter that was 
> incremented when entering a public method and decremented when 
> exiting a public method. But mixins still wanted to call the 
> invariant so what I did was dynamic_cast the mixin this pointer to an 
> Invariant* and call the Invariant method if the result wasn't NULL. 

I've been pondering this.  I think dynamic_cast has a couple of
problems for this usage.  For one thing, it's slower than a virtual
base class lookup.  More importantly, dynamic_cast<C*>(p) returns null
if *p has more than one C in its inheritance hierarchy!  This is
explained in TC++PL, however the text mistakenly says that this
problem only occurs with virtual inheritance.  For example:

B B
| |
C D A
 \|/
  E
  
E inherits from B twice.  dynamic_cast<B*>((A*) ptr to E) returns 0!  I
coded this up, and both GCC and MSVC agree.  I checked with Stroustrup
(the person, not the book), and he agrees too; he's going to correct
the text in TC++PL.

On the other hand, if you *always* use virtual inheritance, the
ambiguity *never* occurs; the above graph looks like:

B
|\
C D A
 \|/
  E

And presuming that B is your base class with the reference count, the
compiler will force you to derive A from B as well, if you try to make
a smart pointer to A.

I realize that you're advocating a hierarchy that looks like this:

B
|
C D A
 \|/
  E

But I don't think there's a good way to enforce that.

-- 
Thatcher Ulrich <tu...@tu...>
http://tulrich.com

[GD-General] RE: Preprocessors

[Steve R. <St...@no...>]

> Or the belief that languages shouldn't have preprocessors because the
> C preprocessor was so gross; inevitably you lose major functionality
> like "#ifdef 0/#endif" and the language designers defend it to the
> end.

I'm glad to see people acknowledging that the C preprocessor is a powerful =
tool and not something to be shunned unconditionally. Used improperly, you =
can cut off your own leg, but the same is true for a chainsaw - yet both =
are still useful tools.

I'm so sick of hearing over and over again about the evils of preprocessors=
 that I'm writing an article for Game Programming Gems 3 on "Finding =
Redeeming Value in C-Style Macros." Since the article is still in-progress,=
 I was wondering if I could pick the brains of the people on this list... =
Currently, I have about eight pretty good macro tricks, but I'm open to =
adding more.

Just to throw one out there, I'll offer the compile time assert:
#define cassert(expn) typedef char __C_ASSERT__[(expn)?1:-1]

For example, if you're working on cross-platform code, you might want to =
check at compile time that enumerations are the same size as an unsigned =
int. Using the previous macro, you can check this by writing:

cassert( sizeof(MyEnum) =3D=3D sizeof(unsigned int) );

As you can see, a good macro trick is something that creatively exploits =
text replacement and makes things easier to understand - not harder. :)

-Steve

Re: [GD-General] Eiffel

[J C L. <cl...@ka...>]

On Wed, 2 Jan 2002 17:40:26 -0000 
Jamie Fowlston <ja...@qu...> wrote:

> That would be nice, but most people I know stick to one OS (per
> machine, at least) so I'd consider it less important for it to
> work across OSs.

As I only reboot (or take a system down) to do OS/kernel upgrades,
so that's the interesting point.  For me a reboot does mean a new
OS. Beyond that as a feature it gets used (in the Galeon and XEmacs
cases in particular) as their versions increment much more rapidly
than my installed kernels) -- so I'll upgrade Galeon, kill the
running instance, and then restart Galeon and restore the prior
session to be back where I was.

> And I like to turn machines off :)

Ahh, a related but somewhat different problem.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
cl...@ka...               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

RE: [GD-General] Eiffel

[Jamie F. <ja...@qu...>]

That would be nice, but most people I know stick to one OS (per machine, at
least), so I'd consider it less important for it to work across OSs. And I
like to turn machines off :)

Jamie


-----Original Message-----
From: J C Lawrence [mailto:cl...@ka...]
Sent: 02 January 2002 17:32
To: Jamie Fowlston
Cc: gam...@li...
Subject: Re: [GD-General] Eiffel


On Wed, 2 Jan 2002 17:09:43 -0000
Jamie Fowlston <ja...@qu...> wrote:

> Indeed; but it would be nice to have an OS that 'just did it' (as
> many laptops are supposed to be able to do, but it's not exactly
> robust in my experience), without having to have it implemented on
> a per-application basis.

Laptops only offer this support in the guise of extended runtimes
for a given OS boot.  I'd though you were considering context
extension across multiple boots, where each reboot may be to a
different (version of) an OS.  For this latter case (X)Emacs,
Galeon, and a very few others offer some support. -- and it would be
great to see such being more common.

--
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Re: [GD-General] Eiffel

[J C L. <cl...@ka...>]

On Wed, 2 Jan 2002 17:09:43 -0000 
Jamie Fowlston <ja...@qu...> wrote:

> Indeed; but it would be nice to have an OS that 'just did it' (as
> many laptops are supposed to be able to do, but it's not exactly
> robust in my experience), without having to have it implemented on
> a per-application basis.

Laptops only offer this support in the guise of extended runtimes
for a given OS boot.  I'd though you were considering context
extension across multiple boots, where each reboot may be to a
different (version of) an OS.  For this latter case (X)Emacs,
Galeon, and a very few others offer some support. -- and it would be
great to see such being more common.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
cl...@ka...               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

RE: [GD-General] Eiffel

[Jamie F. <ja...@qu...>]

Aha! Never knew about that one. Ta. Shall see how well it works :)

Jamie


-----Original Message-----
From: Matt Davies [mailto:ma...@co...]
Sent: 02 January 2002 17:19
To: Jamie Fowlston; gam...@li...
Subject: RE: [GD-General] Eiffel 


You can, sort of, with Windows 2000 by using the Hibernate shutdown option.
Wished Linux had that.


Matt Davies
Programmer, Confounding Factor
ma...@co...
www.confounding-factor.com




-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Jamie Fowlston
Sent: 02 January 2002 14:56
To: gam...@li...
Subject: RE: [GD-General] Eiffel


<Snip>
ObNote: My work system is inherently built on the assumption that my
systems will have uptimes measured in months.  As such I can
establish and preserve such "work contexts" for extended periods,
building and maintaining their value.  Typically I log into my
desktop once and then don't log back out again until I install a new
kernel (once or twice a year).
</Snip>

Although it would be nice to have a system where such things are persistent
regardless of whether or not you leave the machine on.

Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of J
C Lawrence
Sent: 24 December 2001 20:29
To: ph...@me...
Cc: gam...@li...
Subject: Re: [GD-General] Eiffel


On Mon, 24 Dec 2001 11:50:26 -0000
Philip Harris <ph...@me...> wrote:

> I can see why that would cause problems under windows although I
> would guess that your multiple Emacs frames would be one window
> with a lot of children on Windows.

Ahh, MDI.  <retch>

I tend to run windows in terms of contexts.  A virtual desktop will
have a number of windows on it, all applying or related to a given
task.  Typically this will mean a few XEMacs frames, a few xterms, a
few browser windows, etc.  Then repeat that on the next desktop for
the next task (more accurately "frame of mind").

Sometimes its system based.  Currently I have a desktop devoted to
some IPSec work I'm doing on Alice (system name), another devoted to
some InterMezzo stuff going on on Koala, a desktop for root sessions
on various machines (grouped for security reminders), one devoted to
some work stuff I'm doing locally on a protocol stack, another for a
private PHP project, etc

> It's interesting (at least to me) that you find that sort of
> environment so efficient.

I got used to it -- started with the approach roughly 14 years ago
and have never looked back.

> I tend to work the opposite way, the less windows, files and apps
> open at any one time the quicker things move along. Perhaps it's
> Windows imposing its will on me...

At any given time I'll tend to work only on a small subset.  But
then I change subsets fairly regularly.  It might take me several
days, occasionally more than a month, to get back to any particular
context set (private projects particularly tend to suffer such long
gaps), but when I do everything is still there ready and waiting in
the exact same relationship, with the exact same XEmacs edit history
and internal context etc as it had the instant I stopped working on
it -- easy for the mental gears to click back into and start up
again.

ObNote: My work system is inherently built on the assumption that my
systems will have uptimes measured in months.  As such I can
establish and preserve such "work contexts" for extended periods,
building and maintaining their value.  Typically I log into my
desktop once and then don't log back out again until I install a new
kernel (once or twice a year).

  Yeah, its Linux, so I tend to follow the hectic kernel upgrade
  path.  I'd rather do upgrades, and thus reboots, every other year,
  but there are always too many interesting things depending on some
  new kernel rev to tempt me away to upgrading.

> Obviously your approach works very well for you. Do you know of
> other people who work the same way?

I know of a few (perhaps a half dozen), not that many.  Of course a
few of them have copied from me -- usually after having copied my
FVWM RC (which seems to be a viral meme in its own right).

> Is it an apporach you've been using a long time or it still
> evolving?

At the low level it evolves constantly as I adopt new tools and
changes smaller practices.  As you can see from the screenshots
directory I posted a while back, its wasn't that long ago I finally
decided that icons were evil and evicted them from my system.
Similarly I recently moved from Netscape to Galeon (a Gecko based
browser which supports a number of useful UI features such as being
able to restart with all the same windows open and all the same
pages loaded as it had when it was brought down).

My browsing habits haven't changed in detail.  I still follow the
same pattern of reading a page and opening a new window (or TAB in
Galeon's case) on every interesting link as I go along (I almost
never use the forward/back buttons), but now I tend to group pages
in Galeon Windows on a task, character, and interest basis.  As such
I have a Galeon window each containing multiple TABs devoted only to
pages which will require long term study research (typically online
books), another to firewall research, another to IPSec, another to
MUD-Dev, another to blogs, another to performance metrics, another
to Kanga.Nu, another to temp/trash stuff...etc.

> I'm just interested because that sort of approach doesn't seem
> efficient to me at all.

I suspect our work methods are not that different within a single
given project.  In any given contenxt I usually have little going on
(a couple XEmacs frames, a few xterms, a browser or two, a couple
supporting apps, and that's about it).  The likely difference is
that I maintain state and context for many projects and sub-projects
as I go along, that I expect to keep them (and do) for variously
long periods, that I fork such contexts regularly, and that I pop
among them easily.

  I get a lot of startled looks from passersby.

The ticket is not trying to work with them all at once, but building
and storing work contexts such that they're easily context shiftable
among.  Easy support for mental context shifting is the basic
assumption of this work method.

My problem now, and my current big interest in XEMacs UI
development, is seeing how I can shove that same work process down
into editing sessions within XEmacs on a large project.  Too often I
get into a "What is this token and why is it being used quite like
this?" research project, which of course recursively forks as I dig
down into other identical researches on other tokens. I need a way
to tag and lock context frames on those investigations so that I can
later pop back to them, and then usefully pop about among them,
possibly with a matching annotation system.  Barry Warsaw's WinRing
elisp looks very useful as a component for this, but I haven't
settled on a basic approach yet.

--
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general


_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

RE: [GD-General] Eiffel

[Matt D. <ma...@co...>]

You can, sort of, with Windows 2000 by using the Hibernate shutdown option.
Wished Linux had that.


Matt Davies
Programmer, Confounding Factor
ma...@co...
www.confounding-factor.com




-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Jamie Fowlston
Sent: 02 January 2002 14:56
To: gam...@li...
Subject: RE: [GD-General] Eiffel


<Snip>
ObNote: My work system is inherently built on the assumption that my
systems will have uptimes measured in months.  As such I can
establish and preserve such "work contexts" for extended periods,
building and maintaining their value.  Typically I log into my
desktop once and then don't log back out again until I install a new
kernel (once or twice a year).
</Snip>

Although it would be nice to have a system where such things are persistent
regardless of whether or not you leave the machine on.

Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of J
C Lawrence
Sent: 24 December 2001 20:29
To: ph...@me...
Cc: gam...@li...
Subject: Re: [GD-General] Eiffel


On Mon, 24 Dec 2001 11:50:26 -0000
Philip Harris <ph...@me...> wrote:

> I can see why that would cause problems under windows although I
> would guess that your multiple Emacs frames would be one window
> with a lot of children on Windows.

Ahh, MDI.  <retch>

I tend to run windows in terms of contexts.  A virtual desktop will
have a number of windows on it, all applying or related to a given
task.  Typically this will mean a few XEMacs frames, a few xterms, a
few browser windows, etc.  Then repeat that on the next desktop for
the next task (more accurately "frame of mind").

Sometimes its system based.  Currently I have a desktop devoted to
some IPSec work I'm doing on Alice (system name), another devoted to
some InterMezzo stuff going on on Koala, a desktop for root sessions
on various machines (grouped for security reminders), one devoted to
some work stuff I'm doing locally on a protocol stack, another for a
private PHP project, etc

> It's interesting (at least to me) that you find that sort of
> environment so efficient.

I got used to it -- started with the approach roughly 14 years ago
and have never looked back.

> I tend to work the opposite way, the less windows, files and apps
> open at any one time the quicker things move along. Perhaps it's
> Windows imposing its will on me...

At any given time I'll tend to work only on a small subset.  But
then I change subsets fairly regularly.  It might take me several
days, occasionally more than a month, to get back to any particular
context set (private projects particularly tend to suffer such long
gaps), but when I do everything is still there ready and waiting in
the exact same relationship, with the exact same XEmacs edit history
and internal context etc as it had the instant I stopped working on
it -- easy for the mental gears to click back into and start up
again.

ObNote: My work system is inherently built on the assumption that my
systems will have uptimes measured in months.  As such I can
establish and preserve such "work contexts" for extended periods,
building and maintaining their value.  Typically I log into my
desktop once and then don't log back out again until I install a new
kernel (once or twice a year).

  Yeah, its Linux, so I tend to follow the hectic kernel upgrade
  path.  I'd rather do upgrades, and thus reboots, every other year,
  but there are always too many interesting things depending on some
  new kernel rev to tempt me away to upgrading.

> Obviously your approach works very well for you. Do you know of
> other people who work the same way?

I know of a few (perhaps a half dozen), not that many.  Of course a
few of them have copied from me -- usually after having copied my
FVWM RC (which seems to be a viral meme in its own right).

> Is it an apporach you've been using a long time or it still
> evolving?

At the low level it evolves constantly as I adopt new tools and
changes smaller practices.  As you can see from the screenshots
directory I posted a while back, its wasn't that long ago I finally
decided that icons were evil and evicted them from my system.
Similarly I recently moved from Netscape to Galeon (a Gecko based
browser which supports a number of useful UI features such as being
able to restart with all the same windows open and all the same
pages loaded as it had when it was brought down).

My browsing habits haven't changed in detail.  I still follow the
same pattern of reading a page and opening a new window (or TAB in
Galeon's case) on every interesting link as I go along (I almost
never use the forward/back buttons), but now I tend to group pages
in Galeon Windows on a task, character, and interest basis.  As such
I have a Galeon window each containing multiple TABs devoted only to
pages which will require long term study research (typically online
books), another to firewall research, another to IPSec, another to
MUD-Dev, another to blogs, another to performance metrics, another
to Kanga.Nu, another to temp/trash stuff...etc.

> I'm just interested because that sort of approach doesn't seem
> efficient to me at all.

I suspect our work methods are not that different within a single
given project.  In any given contenxt I usually have little going on
(a couple XEmacs frames, a few xterms, a browser or two, a couple
supporting apps, and that's about it).  The likely difference is
that I maintain state and context for many projects and sub-projects
as I go along, that I expect to keep them (and do) for variously
long periods, that I fork such contexts regularly, and that I pop
among them easily.

  I get a lot of startled looks from passersby.

The ticket is not trying to work with them all at once, but building
and storing work contexts such that they're easily context shiftable
among.  Easy support for mental context shifting is the basic
assumption of this work method.

My problem now, and my current big interest in XEMacs UI
development, is seeing how I can shove that same work process down
into editing sessions within XEmacs on a large project.  Too often I
get into a "What is this token and why is it being used quite like
this?" research project, which of course recursively forks as I dig
down into other identical researches on other tokens. I need a way
to tag and lock context frames on those investigations so that I can
later pop back to them, and then usefully pop about among them,
possibly with a matching annotation system.  Barry Warsaw's WinRing
elisp looks very useful as a component for this, but I haven't
settled on a basic approach yet.

--
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general


_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

RE: [GD-General] Eiffel

[Jamie F. <ja...@qu...>]

Indeed; but it would be nice to have an OS that 'just did it' (as many
laptops are supposed to be able to do, but it's not exactly robust in my
experience), without having to have it implemented on a per-application
basis.

Jamie


-----Original Message-----
From: J C Lawrence [mailto:cl...@ka...]
Sent: 02 January 2002 17:07
To: Jamie Fowlston
Cc: gam...@li...
Subject: Re: [GD-General] Eiffel


On Wed, 2 Jan 2002 14:56:23 -0000
Jamie Fowlston <ja...@qu...> wrote:

> Although it would be nice to have a system where such things are
> persistent regardless of whether or not you leave the machine on.

Some tools do offer that.  (X)Emacs does this if you enable session
support, as does Galeon (web browser) does, as it saves the state of
all windows and visible URLs as it goes along with a restart
restoring the previous state.

--
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Re: [GD-General] Eiffel

[J C L. <cl...@ka...>]

On Wed, 2 Jan 2002 14:56:23 -0000 
Jamie Fowlston <ja...@qu...> wrote:

> Although it would be nice to have a system where such things are
> persistent regardless of whether or not you leave the machine on.

Some tools do offer that.  (X)Emacs does this if you enable session
support, as does Galeon (web browser) does, as it saves the state of
all windows and visible URLs as it goes along with a restart
restoring the previous state.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
cl...@ka...               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

RE: [GD-General] Eiffel

[Jamie F. <ja...@qu...>]

<Snip>
ObNote: My work system is inherently built on the assumption that my
systems will have uptimes measured in months.  As such I can
establish and preserve such "work contexts" for extended periods,
building and maintaining their value.  Typically I log into my
desktop once and then don't log back out again until I install a new
kernel (once or twice a year).
</Snip>

Although it would be nice to have a system where such things are persistent
regardless of whether or not you leave the machine on.

Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of J
C Lawrence
Sent: 24 December 2001 20:29
To: ph...@me...
Cc: gam...@li...
Subject: Re: [GD-General] Eiffel


On Mon, 24 Dec 2001 11:50:26 -0000
Philip Harris <ph...@me...> wrote:

> I can see why that would cause problems under windows although I
> would guess that your multiple Emacs frames would be one window
> with a lot of children on Windows.

Ahh, MDI.  <retch>

I tend to run windows in terms of contexts.  A virtual desktop will
have a number of windows on it, all applying or related to a given
task.  Typically this will mean a few XEMacs frames, a few xterms, a
few browser windows, etc.  Then repeat that on the next desktop for
the next task (more accurately "frame of mind").

Sometimes its system based.  Currently I have a desktop devoted to
some IPSec work I'm doing on Alice (system name), another devoted to
some InterMezzo stuff going on on Koala, a desktop for root sessions
on various machines (grouped for security reminders), one devoted to
some work stuff I'm doing locally on a protocol stack, another for a
private PHP project, etc

> It's interesting (at least to me) that you find that sort of
> environment so efficient.

I got used to it -- started with the approach roughly 14 years ago
and have never looked back.

> I tend to work the opposite way, the less windows, files and apps
> open at any one time the quicker things move along. Perhaps it's
> Windows imposing its will on me...

At any given time I'll tend to work only on a small subset.  But
then I change subsets fairly regularly.  It might take me several
days, occasionally more than a month, to get back to any particular
context set (private projects particularly tend to suffer such long
gaps), but when I do everything is still there ready and waiting in
the exact same relationship, with the exact same XEmacs edit history
and internal context etc as it had the instant I stopped working on
it -- easy for the mental gears to click back into and start up
again.

ObNote: My work system is inherently built on the assumption that my
systems will have uptimes measured in months.  As such I can
establish and preserve such "work contexts" for extended periods,
building and maintaining their value.  Typically I log into my
desktop once and then don't log back out again until I install a new
kernel (once or twice a year).

  Yeah, its Linux, so I tend to follow the hectic kernel upgrade
  path.  I'd rather do upgrades, and thus reboots, every other year,
  but there are always too many interesting things depending on some
  new kernel rev to tempt me away to upgrading.

> Obviously your approach works very well for you. Do you know of
> other people who work the same way?

I know of a few (perhaps a half dozen), not that many.  Of course a
few of them have copied from me -- usually after having copied my
FVWM RC (which seems to be a viral meme in its own right).

> Is it an apporach you've been using a long time or it still
> evolving?

At the low level it evolves constantly as I adopt new tools and
changes smaller practices.  As you can see from the screenshots
directory I posted a while back, its wasn't that long ago I finally
decided that icons were evil and evicted them from my system.
Similarly I recently moved from Netscape to Galeon (a Gecko based
browser which supports a number of useful UI features such as being
able to restart with all the same windows open and all the same
pages loaded as it had when it was brought down).

My browsing habits haven't changed in detail.  I still follow the
same pattern of reading a page and opening a new window (or TAB in
Galeon's case) on every interesting link as I go along (I almost
never use the forward/back buttons), but now I tend to group pages
in Galeon Windows on a task, character, and interest basis.  As such
I have a Galeon window each containing multiple TABs devoted only to
pages which will require long term study research (typically online
books), another to firewall research, another to IPSec, another to
MUD-Dev, another to blogs, another to performance metrics, another
to Kanga.Nu, another to temp/trash stuff...etc.

> I'm just interested because that sort of approach doesn't seem
> efficient to me at all.

I suspect our work methods are not that different within a single
given project.  In any given contenxt I usually have little going on
(a couple XEmacs frames, a few xterms, a browser or two, a couple
supporting apps, and that's about it).  The likely difference is
that I maintain state and context for many projects and sub-projects
as I go along, that I expect to keep them (and do) for variously
long periods, that I fork such contexts regularly, and that I pop
among them easily.

  I get a lot of startled looks from passersby.

The ticket is not trying to work with them all at once, but building
and storing work contexts such that they're easily context shiftable
among.  Easy support for mental context shifting is the basic
assumption of this work method.

My problem now, and my current big interest in XEMacs UI
development, is seeing how I can shove that same work process down
into editing sessions within XEmacs on a large project.  Too often I
get into a "What is this token and why is it being used quite like
this?" research project, which of course recursively forks as I dig
down into other identical researches on other tokens. I need a way
to tag and lock context frames on those investigations so that I can
later pop back to them, and then usefully pop about among them,
possibly with a matching annotation system.  Barry Warsaw's WinRing
elisp looks very useful as a component for this, but I haven't
settled on a basic approach yet.

--
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

RE: [GD-General] Re: C++ turing complete

[Jamie F. <ja...@qu...>]

<Snip>
I have a vague recollection of a more practical definition of a
Turing complete language. It went something like: a language is
Turing complete if it has sequential statements, some form of if
statement, and I think one other thing that I can't recall.
</Snip>

One thing that may be useful, that I studied at uni: a URM (unlimited
register machine) is equivalent to a Turing machine. It has 4 instructions:

1. Zero a register
2. Increment a register by 1
3. Set a register to the value of another register
4. If two registers are equal, jump to a program line

This is provably equivalent to a UTM, and tends to be somewhat easier for us
programmer types to understand and use.

So if you can do these things, the language is complete.

Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Jesse Jones
Sent: 24 December 2001 03:49
To: Patrick M Doane
Cc: gam...@li...
Subject: Re: [GD-General] Re: C++ turing complete


At 8:41 PM -0500 12/23/01, Patrick M Doane wrote:
>This is getting off-topic, but this discussion has not been focused
>entirely on gaming, so...
>
>On Sun, 23 Dec 2001, Jesse Jones wrote:
>
>>  My recollection of Turing machines is a bit rusty, but you can use
>>  template meta-programming just like you would use a functional
>>  language and you can also write stuff like compile time if statements
>>  and loops. Sounds Turing complete to me...
>
>This kind of meta-programming is certainly possible to do as long as
>progress is being made (at least in my experience with templates).  For
>example, one can compute factorial numbers using templates because this
>process terminates.
>
>This might be picking on a fine point, but a programming language is
>Turing-complete if it can simulate the behavior of a turing machine with
>finite storage capacity.  One of the fundamental properties of such
>machines is that the halting problem is undecidable.  In fact, Turing
>machines were originally formalized to prove this.  So the idea of being
>Turing-complete while ensuring that computation terminates doesn't seem
>very compatible.

I have a vague recollection of a more practical definition of a
Turing complete language. It went something like: a language is
Turing complete if it has sequential statements, some form of if
statement, and I think one other thing that I can't recall.

>Regardless, templates provide an expressive meta-language for static
>compilation.  I'll admit that I don't fully understand the excitement as
>one can do this in a more powerful (and understandable) fashion by simply
>generating C++ code.

Well, there's a lot of value in being able to generate the code from
within C++. It's more portable and convenient than using something
like Perl and it's better integrated with the other parts of the
language.

   -- Jesse

_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general

Re: [GD-General] RE: Ruby

[Brian H. <bri...@py...>]

At 08:00 PM 12/27/2001 -0800, Jesse Jones wrote:
>BTW one of the really cool things about Ruby is that classes aren't closed.

Same with Obj-C.  You can extend an existing class, sans source code, by 
creating a "category".

@interface ClassToExtend (NewMethods)
- ( int ) newMethod;
@end

You then implement them in a separate implementation area (just like 
regular Obj-C classes), and from that point on you can call those new 
methods directly on the object:

ClassToExtend *c = [[ClassToExend alloc] init];

int i = [c newMethod]; //Call "newMethod" on a class that I didn't write

You can only change the interface, not the implementation, since changing 
the latter would cause a change in the class' size.  There can be some 
problems with name collisions if you're not careful.

Brian

Re: [GD-General] RE: Preprocessors

[Thatcher U. <tu...@tu...>]

On Dec 27, 2001 at 05:57 -0800, Brian Hook wrote:

> For languages like Eiffel and Lua, which lack comment blocks, trying to

In Lua, this works fine:

_ = [[
	commented out stuff....
]]

That's actually a block string assignment, to a variable called '_'.
Nests correctly as well.

-- 
Thatcher Ulrich <tu...@tu...>
http://tulrich.com

[GD-General] RE: Ruby

[Jesse J. <jes...@mi...>]

At 8:55 PM -0500 12/27/01, Patrick M Doane wrote:
>On Thu, 27 Dec 2001, Jesse Jones wrote:
>
>>  Not necessarily. For example, Ruby allows you to stick executable
>>  code outside method definitions so you can do stuff like this:
>>
>>  if want_foo_method() # add foo() to our class if it's OK
>>      def foo(arg1, arg2)    # the foo method
>>         # code goes here
>>      end
>>  end
>>
>>  I'm no Ruby guru yet, but it wouldn't surprise me if you could even
>>  do things like use a loop instead of an if statement and add a bunch
>>  of similar foo1, foo2, etc methods.
>
>TCL has similar functionality which can be very confusing because it
>doesn't follow expected scoping rules.  Procedures declared within
>procedures exist within the global namespace rather than locally as one
>might expect.
>
>I seem to recall that Ruby was a little smarter about this, building
>closures to functions as appropriate.

Ruby doesn't have free functions or nested functions. However you can 
define a method outside a class. If you do this the method is 
automatically added as a private method to the root object class 
which, for all intents and purposes, makes it a global function.

Ruby also has closures which are sort of like in-line nested 
functions that retain their context. The Ruby library classes make 
heavy use of these. Here's an example:

    def accumulate(collection, value = 0)
       collection.each {|entry| value += entry}
       return value
    end

The stuff between the braces is the closure. The each() method calls 
the closure for each item in the collection passing into the closure 
the current item (referenced as entry within the closure).

BTW one of the really cool things about Ruby is that classes aren't 
closed. For example, I was just bitching about std::string not having 
a back() method like *every* other sequential container in the 
standard library. In Ruby this would be trivial to fix. In C++ I have 
to use a free function or something gross like *(str.end() - 1).

   -- Jesse

Re: [GD-General] RE: Preprocessors

[Patrick M D. <pa...@wa...>]

On Thu, 27 Dec 2001, Brian Hook wrote:

> > Or simply that they intend for you to use existing
> > preprocessors.
>
> Fair enough, but then you have source code that won't recompile between
> different build systems because of a different choice of preprocessors.
> Imagine the hell we'd be in today if, for example, things like #if,
> #define, #error, etc. were not standardized in the C language.

Users who want to use the code either use the same preprocessor or must
use the output of the preprocessor.  We have the C preprocessor already,
and can take advantage of reusing it.  Most systems should already have
one available.

A lot could be done for standardizing and improving build environments.
GNU make has done some very good work for Makefiles, but they are still
fairly difficult to learn and maintain.

> In addition, for interpreted languages it may not be feasible to run a
> preprocessor every time you want to load up and run some script.

Ah yes - I don't tend to give the interpreted world too much thought.

> Anyway, my point wasn't necessarily that this is insurmountable, since
> it obviously is not, it's just that in my experience language designers
> get really defensive about this topic.  There's this weird unwillingness
> to admit that commenting out large blocks of code is actually useful.

Hmm.. I'll agree with you about the defensive regarding preprocessors but
commenting out large blocks of code is lexical issue right?

> Typically someone will tell you to use:
>
> if ( 0 ) { put dead code here };
>
> Unfortunately that dead code still needs to compile, so it doesn't help
> when you have some weird parsing error and you're trying to find it.
> For languages like Eiffel and Lua, which lack comment blocks, trying to
> hunt down some parse error can be irritating.  Java at least still
> retains /* */, although you can't nest them.

So these languages have a relatively broken support for comments as you
need them.  Many languages do support nesting comments, especially more
recent ones.

> Of course, I'm sure some Emacs geek will suggest writing some custom
> elisp that prepends each line in a selection with the appropriate line
> comment, be it '--', '//', ';', or '#'.
>
> Hell, for all I know Emacs already has a M-x comment-region-with-#
> command =)

Absolutely, M-x comment-region will work great.  It works based on the
current language mode so you don't have to worry about the different
characters to use. :)

Patrick

[GD-General] RE: Preprocessors

[Brian H. <bri...@py...>]

> Or simply that they intend for you to use existing 
> preprocessors.

Fair enough, but then you have source code that won't recompile between
different build systems because of a different choice of preprocessors.
Imagine the hell we'd be in today if, for example, things like #if,
#define, #error, etc. were not standardized in the C language.

> There is little to stop you from using the C 
> preprocessor as a front-end for most languages out there.

Quite true.  Unfortunately others may opt to use no preprocessor, a
hacked preprocessor, or they'll use Perl and custom syntax, which ends
up causing problems.

In addition, for interpreted languages it may not be feasible to run a
preprocessor every time you want to load up and run some script.

Anyway, my point wasn't necessarily that this is insurmountable, since
it obviously is not, it's just that in my experience language designers
get really defensive about this topic.  There's this weird unwillingness
to admit that commenting out large blocks of code is actually useful.

Typically someone will tell you to use:

if ( 0 ) { put dead code here };

Unfortunately that dead code still needs to compile, so it doesn't help
when you have some weird parsing error and you're trying to find it.
For languages like Eiffel and Lua, which lack comment blocks, trying to
hunt down some parse error can be irritating.  Java at least still
retains /* */, although you can't nest them.

Of course, I'm sure some Emacs geek will suggest writing some custom
elisp that prepends each line in a selection with the appropriate line
comment, be it '--', '//', ';', or '#'.

Hell, for all I know Emacs already has a M-x comment-region-with-#
command =)

Brian

[GD-General] RE: Ruby

[Patrick M D. <pa...@wa...>]

On Thu, 27 Dec 2001, Jesse Jones wrote:

> Not necessarily. For example, Ruby allows you to stick executable
> code outside method definitions so you can do stuff like this:
>
> if want_foo_method() # add foo() to our class if it's OK
>     def foo(arg1, arg2)    # the foo method
>        # code goes here
>     end
> end
>
> I'm no Ruby guru yet, but it wouldn't surprise me if you could even
> do things like use a loop instead of an if statement and add a bunch
> of similar foo1, foo2, etc methods.

TCL has similar functionality which can be very confusing because it
doesn't follow expected scoping rules.  Procedures declared within
procedures exist within the global namespace rather than locally as one
might expect.

I seem to recall that Ruby was a little smarter about this, building
closures to functions as appropriate.

Patrick

[GD-General] Re: Preprocessors

[Patrick M D. <pa...@wa...>]

On Thu, 27 Dec 2001, Brian Hook wrote:

> Or the belief that languages shouldn't have preprocessors because the
> C preprocessor was so gross; inevitably you lose major functionality
> like "#ifdef 0/#endif" and the language designers defend it to the
> end.

Or simply that they intend for you to use existing preprocessors.  There
is little to stop you from using the C preprocessor as a front-end for
most languages out there.

Patrick

RE: [GD-General] Objective Caml (was Ruby opinions)

[Jesse J. <jes...@mi...>]

At 12:23 PM -0800 12/27/01, Brian Hook wrote:
>Or the belief that languages shouldn't have
>preprocessors because the C preprocessor was so gross; inevitably you
>lose major functionality like "#ifdef 0/#endif" and the language
>designers defend it to the end.

Not necessarily. For example, Ruby allows you to stick executable 
code outside method definitions so you can do stuff like this:

if want_foo_method() # add foo() to our class if it's OK
    def foo(arg1, arg2)    # the foo method
       # code goes here
    end
end

I'm no Ruby guru yet, but it wouldn't surprise me if you could even 
do things like use a loop instead of an if statement and add a bunch 
of similar foo1, foo2, etc methods.

   -- Jesse

Re: [GD-General] Eiffel

[Jesse J. <jes...@mi...>]

At 4:56 PM -0500 12/27/01, Thatcher Ulrich wrote:
>On Dec 22, 2001 at 04:30 -0800, Jesse Jones wrote:
>>
>>  Unfortunately MI has a bad reputation in C++. Even people who should
>>  know better like Scot Myers rag on it. But essentially all of the
>>  problems with MI in C++ are because of virtual base classes. So how
>>  do you avoid virtual base classes? By avoiding diamond shaped
>>  inheritance hierarchies.
>>
>>  One way to do this is by using mixin classes. You have your main-line
>>  classes like Widget or Monster or whatever and then you have mixin
>>  classes like ReferenceCountedMixin or ObserverMixin or whatever.
>>  Mixins only descend from other mixins so you never wind up with the
>>  diamond of death.
>
>I've been pondering this.  I've always depended on virtual inheritance
>for effective mixins.  For example, how do you implement smart
>pointers to mixins of ref-counted classes, without virtual
>inheritance?

I assume you're talking about a smart pointer class that requires 
invasive changes to the object it's pointing at. For example, a smart 
pointer class that maintains ref counts and requires that the object 
have a common reference counted implementation. In general I think 
it's better to try to come up with a non-invasive design.

However I have dealt with problems like this. For example, I used to 
have an Invariant class that allowed for DbC-style invariant checks. 
The class had a virtual Invariant method and a counter that was 
incremented when entering a public method and decremented when 
exiting a public method. But mixins still wanted to call the 
invariant so what I did was dynamic_cast the mixin this pointer to an 
Invariant* and call the Invariant method if the result wasn't NULL. 
However I've fairly recently dropped the Invariant class.

   -- Jesse