In article <d1380p$o27$1@digitaldaemon.com>, pragma says...
>
>I couldn't agree more.  In fact, I proposed almost the same exact thing a (long)
>while back. (sorry if that was what you were referring to) ;)
>
>OP: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/8159
>
>Proposal: http://www.prowiki.org/wiki4d/wiki.cgi?Typedef-Block

I missed this the first time around.  It's an intruging idea, particularly in its ability to extend the functionality of primitive types.  Assuming it wouldn't be terribly difficult to implement, I'm all for it.


Sean

In article <d13ggf$10rn$1@digitaldaemon.com>, Lionello Lunesu says...
>
>Well, I thought it could easily be done by just making a method that takes a 'color' but then calling it like some_color.red() instead of red(some_color)... But it didn't work:
>
>The method 'toupper' can be called as string.toupper(), but why can't the same be done for 'color' ? Even without the typedef (using uint) it won't work?

Sadly, this trick only works for arrays.  I would love to see it enabled for primitive types as well.


Sean

> Sadly, this trick only works for arrays.  I would love to see it enabled
for
> primitive types as well.

Aye me too.  Would this eliminate the need for multi-methods ?

Charlie


"Sean Kelly" <sean@f4.ca> wrote in message news:d14u8u$2hks$1@digitaldaemon.com...
> In article <d13ggf$10rn$1@digitaldaemon.com>, Lionello Lunesu says...
> >
> >Well, I thought it could easily be done by just making a method that
takes a
> >'color' but then calling it like some_color.red() instead of
> >red(some_color)... But it didn't work:
> >
> >The method 'toupper' can be called as string.toupper(), but why can't the
> >same be done for 'color' ? Even without the typedef (using uint) it won't
> >work?
>
> Sadly, this trick only works for arrays.  I would love to see it enabled
for
> primitive types as well.
>
>
> Sean
>
>

In article <d14vgd$2j03$1@digitaldaemon.com>, Charles says...
>
>> Sadly, this trick only works for arrays.  I would love to see it enabled
>for
>> primitive types as well.
>
>Aye me too.  Would this eliminate the need for multi-methods ?

If you mean the proposed typedef block trick, then no.  But consistency is generally a good thing, and this could have an interesting impact on template code.


Sean

> Aye me too.  Would this eliminate the need for multi-methods ?

No.  Here you are essentially extending a class or type similar to C#'s partial classes. This is not a multimethod, nor does it replace their functionality.  Multimethods are an elegant way to perform multiple dispatch.  They define relationships between objects.  Where virtual methods use 1-dimensional vtables, multimethods are N-dimensional method tables, because multiple parameters in a multimethod can be "virtual".

If you would like to know more about multimethods, just ask.

-Craig

> If you would like to know more about multimethods, just ask.

I would :).  Been trying to find a good resource on the web, have a link ?

Charlie


"Craig Black" <cblack@ara.com> wrote in message news:d151j0$2l37$1@digitaldaemon.com...
>
> > Aye me too.  Would this eliminate the need for multi-methods ?
>
> No.  Here you are essentially extending a class or type similar to C#'s partial classes. This is not a multimethod, nor does it replace their functionality.  Multimethods are an elegant way to perform multiple dispatch.  They define relationships between objects.  Where virtual
methods
> use 1-dimensional vtables, multimethods are N-dimensional method tables, because multiple parameters in a multimethod can be "virtual".
>
> If you would like to know more about multimethods, just ask.
>
> -Craig
>
>