Jump to page: 1 2 3
Thread overview
Re: class extensions
Aug 29, 2007
Michael Deardeuff
Aug 29, 2007
kris
Aug 29, 2007
Bill Baxter
Aug 29, 2007
Downs
Aug 30, 2007
Alexander Panek
Aug 30, 2007
Alexander Panek
Aug 30, 2007
Lutger
Aug 30, 2007
kris
Aug 30, 2007
kris
Aug 30, 2007
Lars Ivar Igesund
Aug 30, 2007
Alexander Panek
Aug 30, 2007
Lars Ivar Igesund
Aug 30, 2007
Alexander Panek
Aug 31, 2007
janderson
Aug 30, 2007
Lutger
Aug 30, 2007
Bill Baxter
Aug 30, 2007
Brad Roberts
Aug 30, 2007
Bill Baxter
Aug 30, 2007
kris
Aug 30, 2007
Bill Baxter
Aug 30, 2007
Nathan Reed
August 29, 2007
Robert Fraser Wrote:

> Michael Deardeuff Wrote:
> 
> > I am very excited about the future of D. Walter's and Andrei's talk at the conference was awesome.
> > 
> > However, there are still a few quirks to get out:
> > This is regarding slide 9 of the presentation.
> > 
> > I noticed that most people at the conference liked the idea of extending library classes, but were not to pleased with the interchangability of
> > ---
> > foo(a, args)
> > ---
> > and
> > ---
> > a.foo(args)
> > ---
> > like the arrays have.
> 
> Really? I got the feeling it was very well-received. I like the idea quite a bit, not necessarily just for class extensions (I think it might encourage a lower degree of encapsulation, although if the fields are package-private this might be mitigated by adding class extensions in other modules in the same package), but for primitive types.
> 
> > 
> > I have a suggestion: class extensions kindof like C#'s partial classes
> > ----
> > class A {...}
> > ...
> > extension class A {
> >    void foo(args) {...}
> > }
> > ...
> > a.foo(args);
> > ----
> > (maybe the syntax could be "class extension A" or "extension A"...)
> > 
> > In this way class extensions are clearly marked and the syntax is consistent.
> > 
> > It would be easy to add interfaces to the library class:
> > 
> > extension A : Visitable {
> >    void accept(Visitor v) {...}
> > }
> > 
> > Just an idea for you guys, Walter, Andrei, and the community.
> > 
> > --Michael Deardeuff
> > 
> 
> I proposed this a while ago, and I agree this would be a good idea. However, the more I think about it, the more I realize that in a native-compiled language we're talking vtable problems - how do we know when the vtable is finished? If partials are cross-module, it would require recompilation of every involved module, and just be generally problematic.

Excellent point. Blast.
I think it still _is_ a good idea if you scrap the inheritance/vtable problem and only allow extension classes to use the syntax "a.foo(...);"
I guess what I'm getting at is, I don't like the prospect of working with code that in one line is "foo(a, ...);" and the next "a.foo(...);" With the extension class bit it makes it clear that only methods meant as a class extension can (and must) use the "a.foo();" syntax, which I prefer.
And, of course,  I'm in here for myself. j/k. But not really.

--Michael Deardeuff
August 29, 2007
Michael Deardeuff wrote:
> Robert Fraser Wrote:
[snip]
>> I proposed this a while ago, and I agree this would be a good idea. However, the more I think about it, the more I realize that in a native-compiled language we're talking vtable problems - how do we know when the vtable is finished? If partials are cross-module, it would require recompilation of every involved module, and just be generally problematic.
> 
> Excellent point. Blast.
> I think it still _is_ a good idea if you scrap the inheritance/vtable problem and only allow extension classes to use the syntax "a.foo(...);"
> I guess what I'm getting at is, I don't like the prospect of working with code that in one line is "foo(a, ...);" and the next "a.foo(...);" With the extension class bit it makes it clear that only methods meant as a class extension can (and must) use the "a.foo();" syntax, which I prefer.
> And, of course,  I'm in here for myself. j/k. But not really.
> 
> --Michael Deardeuff

Yeah, the proposed extensions raised all kinds of red flags for me at the conference.

Bluntly, it felt like the notion of "structured programming" was being tossed out in favor of "slapdash programming" ... a brand new paradigm to go along with the other(s) being adopted :)
August 29, 2007
kris wrote:
> Michael Deardeuff wrote:
>> Robert Fraser Wrote:
> [snip]
>>> I proposed this a while ago, and I agree this would be a good idea. However, the more I think about it, the more I realize that in a native-compiled language we're talking vtable problems - how do we know when the vtable is finished? If partials are cross-module, it would require recompilation of every involved module, and just be generally problematic.
>>
>> Excellent point. Blast.
>> I think it still _is_ a good idea if you scrap the inheritance/vtable problem and only allow extension classes to use the syntax "a.foo(...);"
>> I guess what I'm getting at is, I don't like the prospect of working with code that in one line is "foo(a, ...);" and the next "a.foo(...);" With the extension class bit it makes it clear that only methods meant as a class extension can (and must) use the "a.foo();" syntax, which I prefer.
>> And, of course,  I'm in here for myself. j/k. But not really.
>>
>> --Michael Deardeuff
> 
> Yeah, the proposed extensions raised all kinds of red flags for me at the conference.
> 
> Bluntly, it felt like the notion of "structured programming" was being tossed out in favor of "slapdash programming" ... a brand new paradigm to go along with the other(s) being adopted :)

It's pretty much the same deal as with property syntax.  A lot of folks think the use of property syntax with a function should need to be enabled explicilty to avoid nonsense like writefln = 5;

But Walter seems to think it's ok the way it is.  Given that, I can definitely see how he'd think making a.foo uniformly interchangable with foo(a) makes sense.  I guess with property syntax and this combined we'll have
   "a.value" == "value(a)" == "value = a"

Which seems pretty weird to me.

--bb
August 29, 2007
Bill Baxter wrote:
> But Walter seems to think it's ok the way it is.  Given that, I can
> definitely see how he'd think making a.foo uniformly interchangable with
> foo(a) makes sense.  I guess with property syntax and this combined
> we'll have
>    "a.value" == "value(a)" == "value = a"
> 
> Which seems pretty weird to me.
> 
> --bb

I actually welcome this as a straightforward way to enable coders to
write out what they mean.
Of course, it can be abused for stuff like writefln="whee", but in many
cases, abusability is related to the power/expressiveness of a feature -
if you can use it to express more, it follows that you can also use it
to express more garbage; however, that doesn't mean you have to.
 --downs
August 30, 2007
kris wrote:
> 
> Yeah, the proposed extensions raised all kinds of red flags for me at the conference.
> 
> Bluntly, it felt like the notion of "structured programming" was being tossed out in favor of "slapdash programming" ... a brand new paradigm to go along with the other(s) being adopted :)

What are the objections to this? Are there technical pitfalls?

I liked to idea very much. It gives a flexible way of object-oriented / object-based programming similar to how I often see it implemented in C. Plus one can achieve a very nice syntactic sugar for call chaining, which is a great benefit I think. I thought this syntax for arrays is generally appreciated, so why not extend it for other types?
August 30, 2007
Lutger wrote:
> kris wrote:
>>
>> Yeah, the proposed extensions raised all kinds of red flags for me at the conference.
>>
>> Bluntly, it felt like the notion of "structured programming" was being tossed out in favor of "slapdash programming" ... a brand new paradigm to go along with the other(s) being adopted :)
> 
> What are the objections to this? Are there technical pitfalls?

Technical? Since when did that become important? ;)

I belong to the "just because you can doesn't mean you should" camp, and feel that perhaps a more holistic view should be taken here? Just don't see this specific idiom as being particularly beneficial, without adding detrimental side-effect that I'll briefly touch on in a moment (it never really had significant value with arrays either, other than perhaps as a means to confuse non-experts O_+)

> I liked to idea very much. It gives a flexible way of object-oriented / object-based programming similar to how I often see it implemented in C. 

And it potentially introduces additional namespace issues, hijacking issues, and compilation errors for large and/or long-term software development projects. The commercial-development space is where D ought to target, if it's to rise well above being just another enthusiasts playground :p

A conservative approach would remove the existing idiom with arrays, rather than propagate it, and address concerns instead by perhaps looking at alternate approaches for supporting 'properties' (C# for example). Are you thinking this makes a good solution for 'properties' in general? As has been discussed recently?

> Plus one can achieve a very nice syntactic sugar for call chaining, 

D provides that already, no? Tango supports call-chaining extensively.

> which is a great benefit I think. I thought this syntax for arrays is generally appreciated, so why not extend it for other types?

Just because some folks apparently like it, and are vocal about it, doesn't necessarily make it "generally appreciated"? That's a problem with newsgroups and forums though ... it's perhaps easy to get a skewed perspective?

As for extending to other types, that's cool! I just feel this particular idiom potentially builds smoldering fires larger than the one(s) it is attempting to extinguish (or perhaps it's not even trying to resolve anything?). If that is the case it is hardly an adequate resolution, and will simply return to bite D in the buttocks.

As such, I suspect alternatives should be given great consideration (or /greater/ consideration) and the relative trade-offs should be weighed appropriately. Yourself, and others, may feel that's not necessary or has been adequately performed already? I don't feel that way, and it's not the impression I got from the conference :-D

(parts of this are written somewhat tongue-in-cheek, as there's only so much one can achieve via this medium. Please just take it as my opinion, and nothing more)
August 30, 2007
"kris" <foo@bar.com> wrote in message news:fb5742$nek$1@digitalmars.com...
>
>> Plus one can achieve a very nice syntactic sugar for call chaining,
>
> D provides that already, no? Tango supports call-chaining extensively.

I think by call-chaining he was referring to cases such as join(reverse(split(toUpper(str)))) vs. str.toUpper.split.reverse.join(). The latter is arguably much more readable than the former.


August 30, 2007
Jarrett Billingsley wrote:
> "kris" <foo@bar.com> wrote in message news:fb5742$nek$1@digitalmars.com...
>>> Plus one can achieve a very nice syntactic sugar for call chaining,
>> D provides that already, no? Tango supports call-chaining extensively.
> 
> I think by call-chaining he was referring to cases such as join(reverse(split(toUpper(str)))) vs. str.toUpper.split.reverse.join(). The latter is arguably much more readable than the former. 

Had completely missed that, Jarret. Thanks, and fair point
August 30, 2007
Bill Baxter wrote:
> [...]
> But Walter seems to think it's ok the way it is.  Given that, I can definitely see how he'd think making a.foo uniformly interchangable with foo(a) makes sense.  I guess with property syntax and this combined we'll have
>    "a.value" == "value(a)" == "value = a"

Oooh it looks like this would be possible to write:

3.times = (int a) { Stdout(a.toUtf8).newline; }

...fun! :D
August 30, 2007
kris wrote:

> Lutger wrote:
>> kris wrote:
>>>
>>> Yeah, the proposed extensions raised all kinds of red flags for me at the conference.
>>>
>>> Bluntly, it felt like the notion of "structured programming" was being tossed out in favor of "slapdash programming" ... a brand new paradigm to go along with the other(s) being adopted :)
>> 
>> I liked to idea very much. It gives a flexible way of object-oriented / object-based programming similar to how I often see it implemented in C.
> 
> And it potentially introduces additional namespace issues, hijacking issues, and compilation errors for large and/or long-term software development projects. The commercial-development space is where D ought to target, if it's to rise well above being just another enthusiasts playground :p

It will also be directly detrimental to maintainability when used for user defined types, as you no longer will be able to decide where a function is implemented by only looking at the call site (given inheritance and polymorphism this can in cases be difficult enough, but at least you have a type hierarchy to look to).

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
« First   ‹ Prev
1 2 3