Walter wrote:
...snip...
> One feature I *am* considering dumping is the properties-as-function-call
> thing. First of all, it isn't implemented, and secondly, it produces
> numerous ambiguities in the semantic parsing. More ambiguities means more
> special case rules and a harder to understand language.

Do you mean 'get'ers and 'set'ers?  They are my favorite OOP concept. Could it be that the ambiguities are due to poor coding techinques? 'Get'ers and 'set'ers seem like a straight-forward, common-sensical way to make encapsulation easy and effective.  (But I'm not the one writing the compiler.)  Just my 2 cents.

Justin

Walter wrote:
> "Bill Cox" <bill@viasic.com> wrote in message
> news:3E7630A8.40404@viasic.com...
> 
>>Some other features of D do add power, but IMO are not used very often
>>in an industrial setting:
>>
>>Function delegates
>>Closures
>>Nested functions
>>
>>None of these particularly bother me, the need for them just doesn't
>>seem to show up much in the EDA code I've seen.  AFAIK C++ still doesn't
>>have closures or nested functions, and if I remember correctly, member
>>pointers took forever to get into the standard.
> 
> These 3 features are strongly interrelated. For examples of their
> usefulness, see:
> 
>     www.digitalmars.com/d/pretod.html
>     www.digitalmars.com/d/ctod.html
>     www.digitalmars.com/d/cpptod.html
> 
> I've noticed in my own C/C++ code those 3 features result in a significant
> shrink of my source code, with better type checking and cleaner syntax.

I've been using nested functions a lot in my code.  It helps me to express them algorithmically - I write a set of nested functions that performs utilities until the main code is a pure implementation of the algorithm.

> One feature I *am* considering dumping is the properties-as-function-call
> thing. First of all, it isn't implemented, and secondly, it produces
> numerous ambiguities in the semantic parsing. More ambiguities means more
> special case rules and a harder to understand language.

It isn't implemented in DMD - it IS in DLI.

I don't like the implicit semantics, although properties are useful in an explicit syntax, particularly with interfaces and rigorous OOP application.  I favour OMG IDL (which I still can't shake off as reading "Oh my God, IDL!"); in interfaces it would be declared as:

   readonly attribute type name; /* Implements a get only. */
   attribute type name; /* Implements get/set. */

So I could drop in, say, the COM IDL and just have to change a couple type names.  Then in implementation, something like:

   attribute type name
   {
      get
      {
         return super.name;
      }

      set (value)
      {
         foobar = value;
      }
   }

Hi, Walter.

Walter wrote:
>>Truth is, I still need convincing before commiting
>>to D.  There is only one reasonably stable compiler, and our code has to
>>run cross-platform.  At a minimum, I require Sun, Linux and Windows XP.
>>  If Walter gives up on this, it's surely dead, which doesn't make me
>>feel comfortable betting on it.
> 
> 
> My making of the front end open source is an attempt to deal with this.

That's a really smart move.  If I weren't so swamped I'd dive in and help with the GCC version.

I read a bit of your source.  It's nice.

>>Also, D does not yet incorporate any
>>features that I'm dying to be able to use in EDA software development.
>>I don't need GC, and can live with assertions rather than contracts.  We
>>already hide the use of almost all pointers.  Features that I think
>>would be really great for EDA haven't made it in.  For example, I have
>>to emulate dynamic object extensions with void pointers and lots of
>>casting.  Dynamic extensions are a requirement in EDA systems built
>>around a common object database.  I still can't reuse simple code like
>>graph modules very well.  Support for code generators is poor,
> 
> 
> How so?

The ability to spread class and module definitions across multiple files would help.  I hate having to read C++ header files, scan for the magic comment, and generate code there.  It's no big deal, though.  It won't make or break D.

Bill

Walter wrote:
> "Bill Cox" <bill@viasic.com> wrote in message
> news:3E7630A8.40404@viasic.com...
> 
>>Some other features of D do add power, but IMO are not used very often
>>in an industrial setting:
>>
>>Function delegates
>>Closures
>>Nested functions
>>
>>None of these particularly bother me, the need for them just doesn't
>>seem to show up much in the EDA code I've seen.  AFAIK C++ still doesn't
>>have closures or nested functions, and if I remember correctly, member
>>pointers took forever to get into the standard.
> 
> 
> These 3 features are strongly interrelated. For examples of their
> usefulness, see:
> 
>     www.digitalmars.com/d/pretod.html
>     www.digitalmars.com/d/ctod.html
>     www.digitalmars.com/d/cpptod.html
> 
> I've noticed in my own C/C++ code those 3 features result in a significant
> shrink of my source code, with better type checking and cleaner syntax.
> 
> One feature I *am* considering dumping is the properties-as-function-call
> thing. First of all, it isn't implemented, and secondly, it produces
> numerous ambiguities in the semantic parsing. More ambiguities means more
> special case rules and a harder to understand language.

Ok... the examples do look cleaner.  I look forward to trying these three features on for size to see how I like them.  I suspect they'll grow on me.

If losing properties-as-function-call simplifies parsing, feel free to do it.  I don't think I'll miss it.

Bill

J C Calvarese wrote:
> Walter wrote:
> ...snip...
> 
>> One feature I *am* considering dumping is the properties-as-function-call
>> thing. First of all, it isn't implemented, and secondly, it produces
>> numerous ambiguities in the semantic parsing. More ambiguities means more
>> special case rules and a harder to understand language.
> 
> 
> Do you mean 'get'ers and 'set'ers?  They are my favorite OOP concept. Could it be that the ambiguities are due to poor coding techinques? 'Get'ers and 'set'ers seem like a straight-forward, common-sensical way to make encapsulation easy and effective.  (But I'm not the one writing the compiler.)  Just my 2 cents.
> 
> Justin

He's not talking about get'ers and set'ers.  Properties are different.

Get'ers and set'ers are a key feature.  Why they didn't make it into C++ or Java I will never understand.

Properties are attributes of types like size that replace constructs like sizeof.  The syntax usually looks like Class.property.  It sounds like there may be some need for a Class.property(parameter) syntax, but I don't know what it would be for.

Bill

"Bill Cox" <bill@viasic.com> wrote in message news:3E76FCB0.2070802@viasic.com...
> >>Also, D does not yet incorporate any
> >>features that I'm dying to be able to use in EDA software development.
> >>I don't need GC, and can live with assertions rather than contracts.  We
> >>already hide the use of almost all pointers.  Features that I think
> >>would be really great for EDA haven't made it in.  For example, I have
> >>to emulate dynamic object extensions with void pointers and lots of
> >>casting.  Dynamic extensions are a requirement in EDA systems built
> >>around a common object database.  I still can't reuse simple code like
> >>graph modules very well.  Support for code generators is poor,
> > How so?
> The ability to spread class and module definitions across multiple files would help.

I understand the problem you're trying to solve with that, but having a module be one piece of source text is important for the semantic analysis.

> I hate having to read C++ header files, scan for the magic
> comment, and generate code there.  It's no big deal, though.  It won't
> make or break D.

This sounds like a good application for a custom text preprocessor.

Bill,

Thanks for allaying my fear.  I'm not well-versed in OOP-speak.  I tend to think of classes as being composed of properties (fields) and methods (functions).  Oops.  I never even realized someone might want to define their own .size for a class.

Justin


Bill Cox wrote:
...snip...
> He's not talking about get'ers and set'ers.  Properties are different.
> 
> Get'ers and set'ers are a key feature.  Why they didn't make it into C++ or Java I will never understand.
> 
> Properties are attributes of types like size that replace constructs like sizeof.  The syntax usually looks like Class.property.  It sounds like there may be some need for a Class.property(parameter) syntax, but I don't know what it would be for.
> 
> Bill
>