View mode: basic / threaded / horizontal-split · Log in · Help
January 24, 2013
Re: Make dur a property?
On 01/24/2013 07:16 PM, Nick Sabalausky wrote:
> On Thu, 24 Jan 2013 11:25:38 -0500
> Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 1/24/13 3:20 AM, Jacob Carlborg wrote:
>>> On 2013-01-24 03:02, Nick Sabalausky wrote:
>>>
>>>> foo.bar() // Perform action
>>>> foo.bar // Access data
>>>
>>> Who says it has to be like this.
>>
>> Agreed. It's an implied, unstated assumption - the most dangerous
>> kind.
>>
>
> It's dangerous to *break*, not to follow.
>

It's somewhat dangerous to assume but not to follow at the same time. No 
significantly stronger statement can be made, which is why this is a 
matter of taste.
January 25, 2013
Re: Make dur a property?
On 01/24/2013 07:12 PM, Andrei Alexandrescu wrote:
> On 1/24/13 11:32 AM, deadalnix wrote:
>> On Thursday, 24 January 2013 at 16:27:02 UTC, Andrei Alexandrescu wrote:
>>> On 1/24/13 3:38 AM, Tommi wrote:
>>>> I've always secretly hated the ambiguity in D's syntax. E.g:
>>>>
>>>> foo.bar
>>>>
>>>> What could foo and bar be? D has many more answers than C++:
>>>>
>>>> D C++
>>>> foo bar foo bar
>>>> Module/Namespace x x
>>>> Type x x
>>>> Variable x x x x
>>>> Method x
>>>> Free function x x
>>>
>>> Nah, C++ has also namespace, inner classes and function-local
>>> classes... lookup and resolution are actually more complicated than D.
>>>
>>
>> No. C++ has no forward references, no UFCS, and no way to introduce new
>> symbols during semantic analysis.
>>
>> C++ is an horrible beast, but on the identifier side, D is far worse.
>
> Well if D is worse, should we give up on forward references, UFCS, or
> mixins?
>
> Andrei

Also, static if and 'is' expressions.
No, but we must specify and implement a sophisticated evaluation model 
of compile-time code evaluation, introspection, and generation 
constructs. DMD gets it wrong. Semantics of code, or whether it is 
accepted may depend on the order modules are passed on the command line.
I'll release what I have got so far later in spring.
January 25, 2013
Re: Make dur a property?
On 2013-01-24 19:16, Nick Sabalausky wrote:

> It's dangerous to *break*, not to follow.

Follow what? There are several languages that don't care if you use 
parentheses when calling a method.

-- 
/Jacob Carlborg
January 25, 2013
Re: Make dur a property?
On Thursday, 24 January 2013 at 18:01:30 UTC, Andrei Alexandrescu 
wrote:
> On 1/24/13 9:25 AM, deadalnix wrote:
>> On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
>> Alexandrescu wrote:
>>> We need a good DIP on this. UFCS has destroyed all arguments 
>>> in favor
>>> of requiring parens. There is no question we must do this. 
>>> Anyone
>>> inclined toward writing a detailed DIP?
>>>
>>
>> Let me strongly disagree. Language feature should never be 
>> introduced
>> where library solution is possible.
>
> Absolutes are difficult positions in language design.
>

This is why I used should and not must.

>> And library solution is possible. And opDispatch makes it 
>> possible.
>
> Problem is, a lot of code would need to add opDispatch. I don't 
> think that's good language design.
>

Not at all, you can provide one via UFCS.
January 25, 2013
Re: Make dur a property?
On 2013-01-24 17:27, Andrei Alexandrescu wrote:

> Nah, C++ has also namespace, inner classes and function-local classes...
> lookup and resolution are actually more complicated than D.

A namespace in C++ would be using a double colon, not a dot.

-- 
/Jacob Carlborg
January 25, 2013
Re: Make dur a property?
On Thursday, 24 January 2013 at 18:12:22 UTC, Andrei Alexandrescu 
wrote:
> Well if D is worse, should we give up on forward references, 
> UFCS, or mixins?
>

No, I don't think we should drop them. I'm just mentioning that 
identifier resolution in harder in D than in C++ , but never said 
that identifier resolution should be easy.
January 25, 2013
Re: Make dur a property?
On Thursday, 24 January 2013 at 19:36:35 UTC, Dmitry Olshansky 
wrote:
> The same argument was brought about overloading  operators, 
> about overloading functions, etc. In other words the argument 
> is WYSIWYG, but humans inherently think in overloaded notions 
> and take obvious shortcuts
> just about everywhere.
>

That is not because it is ambiguous, where . overload behavior 
for pointer isn't.

Such behavior would be like if pointer dereferenced automagically 
and you add to put & everywhere to not dereference them. That 
would be an horrible behavior, as well as calling function 
automatically is an horrible behavior.

So we want to avoid () for convenience. I have noting against 
convenience, but here it is plain wrong :
 - We have 2 syntax to do the same thing.
 - If the return value is callable, it is unclear what is done.
 - We need something to NOT call the function, as it is called 
magically. Let's introduce &funName syntax and mess up with 
another feature.
 - It is now unclear when we take the return address or the 
address of the function.
 - It is also not clear how to pass a function as parameter (we 
have seen the case recently).
 - Depending on the callable, () and & have different behaviors, 
which is error prone, harder to learn for newcomer, harder for 
generic code, and exactly what everybody hate about C++ .

I have nothing against convenience, and like very much the 
pointer + dot behavior. I actuelly proposed something similar 
with functions : function.identifier can call the function 
without (), which is the equivalent of the pointer thing in term 
of convenience. Going further inherently mess up with other 
features of the language.
January 25, 2013
Re: Make dur a property?
Am Fri, 25 Jan 2013 00:11:24 +0100
schrieb Timon Gehr <timon.gehr@gmx.ch>:

> On 01/24/2013 04:45 PM, Johannes Pfau wrote:
> > Am Thu, 24 Jan 2013 09:20:44 +0100
> > schrieb Jacob Carlborg <doob@me.com>:
> >
> >> On 2013-01-24 03:02, Nick Sabalausky wrote:
> >>
> >>> foo.bar() // Perform action
> >>> foo.bar   // Access data
> >>
> >> Who says it has to be like this.
> >>
> >
> > .NET guidelines since .NET 1.1 for example:
> >
> > "In general, methods represent actions and properties represent
> > data." (http://msdn.microsoft.com/en-us/library/bzwdh01d%28v=vs.71%29.aspx).
> >
> 
> This is not C#.

I think I misunderstood the question. If the question was whether the
parenthesis mark an action as opposed to data access, then my
statement is of course void. (But it's a tradition from C that () mark
function calls).

I thought he meant properties should be used for data access. This is
almost by definition: Java used setX /getX, C# formalized that into
properties, D took properties from C#. Properties where always used
for data access, if you don't use properties for data access but for
other things the whole concept doesn't make sense. So in that case
"this is C#".

Properties are polymorphic fields, nothing more nothing less. The D
implementation is horrible though as you can't do  stuff like
x.field++. However, how would you implement this without properties and
fields:

x.value++; //Field or property
x.setValue(x.getValue()++); //How ugly...
x.setValue(x.getValue++); //Really ugly (optional parentheses func call)

You can't allow these rewrites for normal functions, it'll be a
disaster and this is why we need properties. And it's also the reason
why properties are data: they're fields and fields are data.
January 25, 2013
Re: Make dur a property?
On Thursday, 24 January 2013 at 23:11:25 UTC, Timon Gehr wrote:
> This is not C#.
Ye, exactly. Contrary to C#, our properties suck.
January 25, 2013
Re: Make dur a property?
On 01/25/2013 05:56 PM, Johannes Pfau wrote:
> Am Fri, 25 Jan 2013 00:11:24 +0100
> schrieb Timon Gehr <timon.gehr@gmx.ch>:
>
>> On 01/24/2013 04:45 PM, Johannes Pfau wrote:
>>> Am Thu, 24 Jan 2013 09:20:44 +0100
>>> schrieb Jacob Carlborg <doob@me.com>:
>>>
>>>> On 2013-01-24 03:02, Nick Sabalausky wrote:
>>>>
>>>>> foo.bar() // Perform action
>>>>> foo.bar   // Access data
>>>>
>>>> Who says it has to be like this.
>>>>
>>>
>>> .NET guidelines since .NET 1.1 for example:
>>>
>>> "In general, methods represent actions and properties represent
>>> data." (http://msdn.microsoft.com/en-us/library/bzwdh01d%28v=vs.71%29.aspx).
>>>
>>
>> This is not C#.
>
> I think I misunderstood the question. If the question was whether the
> parenthesis mark an action as opposed to data access, then my
> statement is of course void. (But it's a tradition from C that () mark
> function calls).
>
> I thought he meant properties should be used for data access. This is
> almost by definition: Java used setX /getX, C# formalized that into
> properties, D took properties from C#. Properties where always used
> for data access, if you don't use properties for data access but for
> other things the whole concept doesn't make sense. So in that case
> "this is C#".
> ...

I think he meant both. =)
8 9 10 11 12 13
Top | Discussion index | About this forum | D home