I agree, but it's a standard, and it's better to have a standard than not.

There are some aspects of the current naming scheme that works nicely with properties. But then properties have problems all their own at the moment ...

"Dejan Lekic" <leka@entropy.tmok.com> wrote in message news:d086f9$2kbb$1@digitaldaemon.com...
>
> I very much dislike choice of having JAVA-like functionNames... That
> might
> even come to turning back to D. :( I thought pretty much about resons
> behind using that naming convention and there was none good reason i
> could
> come to. Seriously.
> Someone pointed out that people use it to distinct from class-names.
> Well,
> if i have dot (".") before it, it cannot be the class! :)
> Anyway it's up to D developers and they made their decision - this is
> just a
> personal note.
> I prefer MethodNames() or method_names() . methodNames() are
> unacceptable
> for my projects. :)
> IMHO it would be good if D doesn't make difference between those
> somehow. :)
>
> Kind regards
>
> -- 
> ...........
> Dejan Lekic
>  http://dejan.lekic.org
> 

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsm244zh323k2f5@ally...
> On Thu, 03 Mar 2005 17:27:17 -0500, Carlos Santander B. <csantander619@gmail.com> wrote:
>> Walter wrote:
>>>  I put it in so that arrays and basic types could be extended by the
>>> programmer to have generic 'property' like features. It should go in the
>>> spec, you're right.
>>>
>>
>> I see a problem. When two functions with the same name in different modules collide, you have to use the module.function(args) syntax. But with arg.function(more,args), there's no help. DMD will just say "a.d(1): function a.foo conflicts with b.foo at b.d(1)". While it's not critical, it might cause problems, and eventually someone will say that we'd better off without it. So, how would we disambiguate (sp?) ?
>
> Assuming:
>
> path.module1.foo(char[] a, int i);
> path.module2.foo(char[] a, int i);
>
> char[] a;
> a.path.module1.foo(1);
> a.path.module2.foo(2);
>
> perhaps?
>
But how would the global scope resolution operator work? Something like this maybe?:

a..foo(1);

Although maybe that would cause problems for the compiler distinguishing it from the array slicing use of '..'?

> or maybe it's better to force the user to revert to:
>
> path.module1.foo(a,1);
> path.module2.foo(a,2);
>
>> Also, right now, it only works with arrays, not basic types, classes, structs, unions or enums.
>
> It would be kewl if it worked with all types, if so, how should it handle:
>
> class A {
>   void foo() {
>   }
> }
>
> void foo(A a) {
> }
>
> A a = new A();
> a.foo(); //which do we call?
>
> The same applies to struct, union, and when the function clashes with a property of a basic type or array.
>
> Regan

It makes sense to use on arrays and basic types because they have no other way to use blah.func() syntax. But, I don't think it should be allowed for classes because it would lead to major abuses to the ideas of a class and encapsulation. For instance, adding "member functions" to a class without actually inhereting it.

Although maybe that would be good...? I guess it just feels kinda dangerous to me.

> Walter, you're a good developer but you should only publish new releases when you don't break existing (and syntactically error-free) code (DStress?)
>
That makes sense for post-1.0 releases, but pre-1.0 should be able to break existing code if a good reason arises. This prevents the language from prematurely backing itself into a corner from decicions that later turn out to be bad choices.

"Dejan Lekic" <leka@entropy.tmok.com> wrote in message news:d086f9$2kbb$1@digitaldaemon.com...
>
> I very much dislike choice of having JAVA-like functionNames... That might
> even come to turning back to D. :( I thought pretty much about resons
> behind using that naming convention and there was none good reason i could
> come to. Seriously.
> Someone pointed out that people use it to distinct from class-names. Well,
> if i have dot (".") before it, it cannot be the class! :)
> Anyway it's up to D developers and they made their decision - this is just
a
> personal note.
> I prefer MethodNames() or method_names() . methodNames() are unacceptable
> for my projects. :)
> IMHO it would be good if D doesn't make difference between those somehow.
:)

D, the language, does not prescribe naming conventions. Feel free to use whatever makes sense for your project.

For purely stylistic reasons, however, it's a good idea for the standard library for D to follow some sort of convention. One convention is as good as another, it's consistency that matters. For better or worse, the current Phobos convention is what it is, there's too much water under that bridge.

On Thu, 3 Mar 2005 18:54:48 -0500, Nick Sabalausky <z@a.a> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opsm244zh323k2f5@ally...
>> On Thu, 03 Mar 2005 17:27:17 -0500, Carlos Santander B.
>> <csantander619@gmail.com> wrote:
>>> Walter wrote:
>>>>  I put it in so that arrays and basic types could be extended by the
>>>> programmer to have generic 'property' like features. It should go in the
>>>> spec, you're right.
>>>>
>>>
>>> I see a problem. When two functions with the same name in different
>>> modules collide, you have to use the module.function(args) syntax. But
>>> with arg.function(more,args), there's no help. DMD will just say
>>> "a.d(1): function a.foo conflicts with b.foo at b.d(1)". While it's not
>>> critical, it might cause problems, and eventually someone will say that
>>> we'd better off without it. So, how would we disambiguate (sp?) ?
>>
>> Assuming:
>>
>> path.module1.foo(char[] a, int i);
>> path.module2.foo(char[] a, int i);
>>
>> char[] a;
>> a.path.module1.foo(1);
>> a.path.module2.foo(2);
>>
>> perhaps?
>>
> But how would the global scope resolution operator work? Something like this
> maybe?:
>
> a..foo(1);
>
> Although maybe that would cause problems for the compiler distinguishing it
> from the array slicing use of '..'?

Good point. Yuck.

I think then, the solution is that in cases where there is conflict you have to specify the name in full and pass the parameter.

I think this feature is still incredibly useful.

This one problem does not detract much, if anything from it's usefulness.

Regan

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsm27utj923k2f5@ally...
> On Thu, 3 Mar 2005 18:54:48 -0500, Nick Sabalausky <z@a.a> wrote:
>> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsm244zh323k2f5@ally...
>>> On Thu, 03 Mar 2005 17:27:17 -0500, Carlos Santander B. <csantander619@gmail.com> wrote:
>>>> Walter wrote:
>>>>>  I put it in so that arrays and basic types could be extended by the
>>>>> programmer to have generic 'property' like features. It should go in
>>>>> the
>>>>> spec, you're right.
>>>>>
>>>>
>>>> I see a problem. When two functions with the same name in different
>>>> modules collide, you have to use the module.function(args) syntax. But
>>>> with arg.function(more,args), there's no help. DMD will just say
>>>> "a.d(1): function a.foo conflicts with b.foo at b.d(1)". While it's not
>>>> critical, it might cause problems, and eventually someone will say that
>>>> we'd better off without it. So, how would we disambiguate (sp?) ?
>>>
>>> Assuming:
>>>
>>> path.module1.foo(char[] a, int i);
>>> path.module2.foo(char[] a, int i);
>>>
>>> char[] a;
>>> a.path.module1.foo(1);
>>> a.path.module2.foo(2);
>>>
>>> perhaps?
>>>
>> But how would the global scope resolution operator work? Something like
>> this
>> maybe?:
>>
>> a..foo(1);
>>
>> Although maybe that would cause problems for the compiler distinguishing
>> it
>> from the array slicing use of '..'?
>
> Good point. Yuck.
>
> I think then, the solution is that in cases where there is conflict you have to specify the name in full and pass the parameter.
>
> I think this feature is still incredibly useful.
>
> This one problem does not detract much, if anything from it's usefulness.
>
> Regan

Well, I'm not sure it means we couldn't keep the "disambiguate-ing" syntax, just that we probably couldn't use it for global resolution. Although, maybe it would be better to have consistency from disallowing it across all name collisions, like you said.

Nick Sabalausky wrote:
> 
> 
> It makes sense to use on arrays and basic types because they have no other way to use blah.func() syntax. But, I don't think it should be allowed for classes because it would lead to major abuses to the ideas of a class and encapsulation. For instance, adding "member functions" to a class without actually inhereting it.
> 
> Although maybe that would be good...? I guess it just feels kinda dangerous to me. 
> 
> 


Good point. Now I agree they shouldn't be allowed for classes and structs. Unions and enums would be ok, I think?

_______________________
Carlos Santander Bernal

On Thu, 03 Mar 2005 19:51:15 -0500, Carlos Santander B. <csantander619@gmail.com> wrote:
> Nick Sabalausky wrote:
>>   It makes sense to use on arrays and basic types because they have no other way to use blah.func() syntax. But, I don't think it should be allowed for classes because it would lead to major abuses to the ideas of a class and encapsulation. For instance, adding "member functions" to a class without actually inhereting it.

I don't think it's an abuse of encapsulation. You're not getting any more access to the class eg.

class A {}
void foo(A a) {}

foo cannot modify/access 'a' as much as a real member function could, it just looks like one.

>>  Although maybe that would be good...? I guess it just feels kinda dangerous to me.
>
>
> Good point. Now I agree they shouldn't be allowed for classes and structs. Unions and enums would be ok, I think?

Unions can have member functions too.

Regan

In article <d06p3m$2c55$1@digitaldaemon.com>, Stewart Gordon says...
>
>Anders F Björklund wrote:
>> Roberto Mariottini wrote:
><snip>
>>> I'm still convinced that the big Java success was due to a standard library and a standard GUI. This was the boost that converted a little language to do web pages to one of the most used programming language in the world.
>
>How did Java "do web pages" before it had a "standard GUI"?

I was somewhat unclear, I mean that since it had a standard library and a standard GUI from the beginning, after having been used to do web pages (and showed to be useful) it has been used to do serious development.

Ciao

In article <d06qfa$2d78$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
[...]
>
>I just meant that Java and Java 2 are really different beasts ? And some say that JDK 1.5 really forms a new "Java 3" language.

This doesn't change anything. The success of Java is due to having a big (and
bigger, and bigger) library and a working (and better, and better) GUI from the
beginning. JBuilder, Visual Age, and other IDE did the rest.
Theese three items made the big Java commercial success.

Ciao