July 20, 2008
Nick Sabalausky wrote:
>> I think it should be used to address to the function itself, like typeof(func), func.stringof, func.mangleof, etc.
>>
>> func() <- function result
>> &func  <- function pointer
>> func   <- function itself
> 
> I've always liked in other languages where the "function pointer/reference" and "function itself" are considered one and the same. This just seems like extra unnecessary complexity.
> 
> 

For what it's worth, I'd hate that. A symbol is not its address.

It would be the same as saying "float f. I'd like f and &f to be the same. "

It's simply not true.

(I blame C)

 --downs
August 04, 2008
Tomasz Sowiñski wrote:
> Mike Wrote:
> 
>> For me it's mostly that there's a clear _VISUAL_ distinction between "this  does something" (parens) and "this is data" (no parens); and in D there's  no difference in this one (arbitrary) edge case. It's easy to "eyeball  scan" code using parens pairs as visual anchors.
>>
> 
> I agree. When coding, at first, I was glad to be able to snip the parens (makes code look cleaner), but then I came to the same conclusion - the illusory cleanness of code strikes back in the form of trouble with telling "something" and "do something" apart.
> 
> C# has proper properties. Why mess with the classic?
> 
> Tomek

I agree. In the few D code I've written, I've already run into several bouts with that problem. I'm sure it looked cool at first ("hey, here's a simple trick that allows one to implement properties cleanly"), but while it implements properties "cleanly", it messes up function invocation and introspection *a lot*... :(

I think the ommitable parenthesis syntax should be removed, and a proper syntax for properties created (and I don't mind that the first is done before the second is).

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
August 04, 2008
Jarrett Billingsley wrote:
> "Mike" <vertex@gmx.at> wrote in message news:op.uejk9fs8kgfkbn@lucia...
>> On Sat, 19 Jul 2008 15:32:36 +0200, Koroskin Denis <2korden+dmd@gmail.com> wrote:
>>
>>> Why not have special syntax for properties, like:
>> This has come up multiple times - that's one of the few things where C# wins over D. If I may repeat a suggestion I made once, maybe Walter can be hypnotized into implementing it if I just repeat it often enough :)
>>
>> class foo
>> {
>>     private int _bar;
>>     property int bar
>>     {
>>         opGet() { return _bar; }
>>         opSet(auto value) { _bar = value; }
>>         opAddAssign(auto value) { _bar += value; } // it's extremely extendable!
>>     }
> 
> I agree, but having to reimplement the opXxxAssign methods for every property would quickly become tedious.  A much simpler way to do it is to define that:
> 
> obj.property op= expr;
> 
> is exactly the same as:
> 
> obj.property.opSet(obj.property.opGet() op expr);
> 
> I believe C# does this.  Still it'd be nice to allow opXxxAssign for properties to overload the default behavior, but it'd at least have a reasonable fallback.
> 

I agree, there is not worth in having to define another accessor other than get or set.

My initial brainstorming gives me this design:

class Foo {

  private int bar;

  int op_bar() { return bar; } // getter
  int op_bar(int value) { return bar = value; } // setter

}

No additional "property" syntax is required. You may note that this is more redundant (both the "int" type and the "bar" name have duplicate occurrences). However, if your properties have default getters and setters (the ones that only get and set respectively), then you can just use a mixin to avoid the redundancies:


class Foo {

  private int bar; mixin(propGetSet!(bar));

}


> 
> None of this will ever get into D. 
> 
> 

Most likely :(
And it sucks because the implicit function call syntax is more problem than worth.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
August 04, 2008
"Bruno Medeiros" <brunodomedeiros+spam@com.gmail> wrote in message news:g77dh7$1k7q$1@digitalmars.com...

> My initial brainstorming gives me this design:
>
> class Foo {
>
>   private int bar;
>
>   int op_bar() { return bar; } // getter
>   int op_bar(int value) { return bar = value; } // setter
>
> }
>
> No additional "property" syntax is required. You may note that this is more redundant (both the "int" type and the "bar" name have duplicate occurrences). However, if your properties have default getters and setters (the ones that only get and set respectively), then you can just use a mixin to avoid the redundancies:
>
>
> class Foo {
>
>   private int bar; mixin(propGetSet!(bar));
>
> }

I kind of like that.  One of the things that a true property construct would enable, however, is better information when introspecting types.  I know that in writing the binding library for MiniD (and Kirk has encountered this in PyD as well), I've really wished that there were some way to get the getter/setter(s) of a property given a name, instead of having to derive those types and running the risk that the class writer did something weird, like having two params on the setter with the second one optional.  If we had true properties, the language could be queried for this kind of information and types would be restricted.

> Most likely :(
> And it sucks because the implicit function call syntax is more problem
> than worth.

I feel the same about const-correctness.  Sigh, whatever.

OT, you often tend to reply about two weeks late.  Why is that?


August 11, 2008
Jarrett Billingsley wrote:
> 
> OT, you often tend to reply about two weeks late.  Why is that? 
> 
> 

Nowadays I'm much more busy than I used to be, so trying to keep with the newsgroups is more complicated. I usually only have time for that in the weekends.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
1 2 3 4
Next ›   Last »