Re: Uniform Function Call Syntax?
On Tue, 08 Mar 2016 18:59:47 +, Ola Fosheim Grøstad wrote: > On Monday, 7 March 2016 at 19:09:47 UTC, Chris Wright wrote: >> I don't think history bears that out. I've never seen this happen in >> Java, C#, or Python. > > You haven't seen people do it in D? No.
Re: Uniform Function Call Syntax?
On Monday, 7 March 2016 at 19:09:47 UTC, Chris Wright wrote: I don't think history bears that out. I've never seen this happen in Java, C#, or Python. You haven't seen people do it in D?
Re: Uniform Function Call Syntax?
On 07.03.2016 01:19, Xinok wrote: On Sunday, 6 March 2016 at 07:45:58 UTC, Ola Fosheim Grøstad wrote: I think it would be better idea to just add the ability to add unicode operators, and to avoid precedence issues one could just require them to use parentheses. That way you could define opCustom"•" and use it as: ( point1 • point2 ) Please no. If I need to open up Character Map just to write code, something has gone horribly wrong. That "something" is your editor configuration. Seriously, this is a trivial problem.
Re: Uniform Function Call Syntax?
On 07.03.2016 18:49, Wyatt wrote: But I really don't want any language features predicated on the programmer having an APL keyboard. I can't think of any language feature that would be.
Re: Uniform Function Call Syntax?
On Monday, 7 March 2016 at 18:57:03 UTC, Chris Wright wrote: It's still not inconsistent to disallow math symbols. It is inconsistent if you accept that different communities have different notations/languages. Why you would you want to exclude the scientific community? here: I want to guide people toward using descriptive names, because that makes it easier to read code, which makes it easier to verify correctness. Err, no, the contrary. What you get is an incomprehensible and overly verbose mess that hide problems and/or result in excessive overloading of the "*" symbol. Try some geometric computing problems, it gets messy quickly. People don't write descriptive names, they write short names, if you provide a very limited set of symbols. Like "dot".
Re: Uniform Function Call Syntax?
On Mon, 07 Mar 2016 18:45:34 +, Ola Fosheim Grøstad wrote: > There are lots of interesting letters from various languages that can be > used, so prohibiting access to the proper symbols is kinda pointless. > The end result is that people just pick inappropriate characters > instead. I don't think history bears that out. I've never seen this happen in Java, C#, or Python.
Re: Uniform Function Call Syntax?
On Mon, 07 Mar 2016 18:45:34 +, Ola Fosheim Grøstad wrote: > On Monday, 7 March 2016 at 18:35:44 UTC, Chris Wright wrote: >> The partial integral symbol is not a letter or digit under any >> circumstances. It is a mathematical symbol. Identifiers cannot contain >> mathematical symbols in D or C99 or even C#. > > Well, but that argument is kinda bogus. Scientists have "invented" their > own notation using whatever symbols (characters) > they had access to since forever. It's not like they will stop just > because language designers are reactionary. :-) It's still not inconsistent to disallow math symbols. There's a simple rule that the C99 standards writers were attempting to approximate, and that simple rule excludes mathematical symbols. You dislike and disagree with that decision, which is a separate complaint. I'm sympathetic to the language designers here: I want to guide people toward using descriptive names, because that makes it easier to read code, which makes it easier to verify correctness. Math notation tends to be very compact and inscrutable, and I don't want to encourage users of my language to use inscrutable identifiers.
Re: Uniform Function Call Syntax?
On Mon, 07 Mar 2016 12:58:51 +, Lass Safin wrote: > Have you ever heard of .XCompose? > For linux: https://github.com/kragen/xcompose For windows: > https://github.com/samhocevar/wincompose How it works: > You choose a compose key, then use it to compose special characters with > specific sequences. Alternatively, you can create a custom keyboard layout for Linux relatively easily. The text format is relatively legible, but to simplify, you can use a utility such as https://github.com/simos/keyboardlayouteditor . For instance, I find myself using the characters ðþƹāē often for personal reasons, plus åøæ when I was learning Norwegian, so I created a keyboard layout to simplify that. Still doesn't make it a great idea, but if your code's audience is sufficiently constrained, you might find it makes some things more usable.
Re: Uniform Function Call Syntax?
On Monday, 7 March 2016 at 18:35:44 UTC, Chris Wright wrote: The partial integral symbol is not a letter or digit under any circumstances. It is a mathematical symbol. Identifiers cannot contain mathematical symbols in D or C99 or even C#. Well, but that argument is kinda bogus. Scientists have "invented" their own notation using whatever symbols (characters) they had access to since forever. It's not like they will stop just because language designers are reactionary. :-) There are lots of interesting letters from various languages that can be used, so prohibiting access to the proper symbols is kinda pointless. The end result is that people just pick inappropriate characters instead.
Re: Uniform Function Call Syntax?
On Mon, 07 Mar 2016 10:32:09 +, Ola Fosheim Grøstad wrote: > D is inconsistent in what parts > of unicode you can use in names though. The basic idea is that you can use any letter or '_' as the first element of an identifier, and you can use any letter or number or '_' as a subsequent element of an identifier. That's simple and consistent, right? Except it's based on C99's fixed list of characters. So the actual rule is, you can use symbols from about 25 different writing systems that the designers of C99 thought prevalent enough to include, so long as they were in Unicode before 1999. C#, in contrast, uses Unicode categories. You can use the Cherokee alphabet in C# identifiers, and there are under 400,000 speakers of Cherokee. Making that work took far less effort for the C# standard authors than the choice of identifier characters for C99. I'm relatively certain that Walter went with C99's rules in large part because he had already implemented them, whereas he didn't have a readily available library with an appropriate license to give the Unicode category for a given codepoint. > But you can already use "π" in D code? U+03C0 (π) is from the Greek alphabet section of the Unicode inventory. It's for writing in the Greek language, which is currently spoken by about thirteen million people. It is primarily a letter, with incidental usage as a mathematical symbol. Therefore, based on the rule that you can always start an identifier with a letter, you can use π as an identifier. > I don't think you can use "∂"... The partial integral symbol is not a letter or digit under any circumstances. It is a mathematical symbol. Identifiers cannot contain mathematical symbols in D or C99 or even C#.
Re: Uniform Function Call Syntax?
On Monday, 7 March 2016 at 17:49:35 UTC, Wyatt wrote: I've mentioned this before, but I think a constrained set of user-defined operators using annotations/affixes on the existing set is a better fit for D. It's a lesson well-learned from other languages (cf. OCaml; F#), and fits with D's generally practical bent. Not sure what you mean by annotations/affixes and what lesson there is to be learned? What problems have other languages had with this? I mean, if you want to alias them to Lucky Charms or various hieroglyphs of birds disemboweling men later, I guess maybe that's could work? But I really don't want any language features predicated on the programmer having an APL keyboard. I don't see how mixfix notation makes this "problem" larger than the current prefix notation. Why is the current situation that allows "ø(x,y)" less problematic than the proposed "(x ø y)" ?
Re: Uniform Function Call Syntax?
On Sunday, 6 March 2016 at 07:45:58 UTC, Ola Fosheim Grøstad wrote: I think it would be better idea to just add the ability to add unicode operators, and to avoid precedence issues one could just require them to use parentheses. That way you could define opCustom"•" and use it as: I've mentioned this before, but I think a constrained set of user-defined operators using annotations/affixes on the existing set is a better fit for D. It's a lesson well-learned from other languages (cf. OCaml; F#), and fits with D's generally practical bent. I mean, if you want to alias them to Lucky Charms or various hieroglyphs of birds disemboweling men later, I guess maybe that's could work? But I really don't want any language features predicated on the programmer having an APL keyboard. -Wyatt
Re: Uniform Function Call Syntax?
On Monday, 7 March 2016 at 07:58:53 UTC, Era Scarecrow wrote: On Monday, 7 March 2016 at 06:57:48 UTC, Ola Fosheim Grøstad wrote: immutable π = 3.14; Oh, the horror! With the assumption pi is declared elsewhere (say, in std.math), what i wonder is the number for pi vs 2 letters. Unicode 03C0h, so now i have to convert that to decimal, code 960. Alt+960 = └ That's not pi... Looking up the symbol by itself in the character map was annoying enough. No, this is not a good idea unless it's easily accessible, preferably with 2 or fewer keystrokes to symbolize pi. As a reminder most of us are programmers, not scientists or mathematicians. Having specialized symbols won't give us any benefit. It's not like we're filling out a complex formula with college level math for a thesis. Have you ever heard of .XCompose? For linux: https://github.com/kragen/xcompose For windows: https://github.com/samhocevar/wincompose How it works: You choose a compose key, then use it to compose special characters with specific sequences. Examples: ComposeKey, *, p: π. ComposeKey, s, s: ß ComposeKey, ComposeKey, d, e, g, c (degree Celsius): ℃ It is not impossible to use unicode special characters on a daily base easily, with the use of this tool. No need to use the character map or anything. I think it would be very nice, if one had the option of using these special characters. E.g. → instead of >>, if you desire that; std.math defining π as π. Small gimmicks like these are things I find to be good for a language to have.
Re: Uniform Function Call Syntax?
On Monday, 7 March 2016 at 07:58:53 UTC, Era Scarecrow wrote: On Monday, 7 March 2016 at 06:57:48 UTC, Ola Fosheim Grøstad wrote: immutable π = 3.14; Oh, the horror! With the assumption pi is declared elsewhere (say, in std.math), what i wonder is the number for pi vs 2 letters. Unicode 03C0h, so now i have to convert that to decimal, code 960. Alt+960 = └ That's not pi... Looking up the symbol by itself in the character map was annoying enough. No, this is not a good idea unless it's easily accessible, preferably with 2 or fewer keystrokes to symbolize pi. But you can already use "π" in D code? D is inconsistent in what parts of unicode you can use in names though. I don't think you can use "∂"... As a reminder most of us are programmers, not scientists or mathematicians. Having specialized symbols won't give us any benefit. It's not like we're filling out a complex formula with college level math for a thesis. Well, but you already have this possibility in D. Adding custom operators is just a small extension. And you don't have to use it if you don't want to. There is no standard english notation for the inner product either, "dot" refers to the sigil... But if you want both, you can have both. You can both have "innerProduct(v1,v2)" and "(v1 • v2)". In a commercial setting you want as high level of legibility as possible. D is doing slightly better than C++, but is far away from providing a good legible syntax. More time is spent reading code than writing it. In some cases people want to use their own language. D supports that. Math notation is no different than using a non-english language in that regard. Why shouldn't mathematicians be allowed to user the language they are familiar with if national languages are supported?
Re: Uniform Function Call Syntax?
On Monday, 7 March 2016 at 07:58:53 UTC, Era Scarecrow wrote: On Monday, 7 March 2016 at 06:57:48 UTC, Ola Fosheim Grøstad wrote: immutable π = 3.14; Oh, the horror! With the assumption pi is declared elsewhere (say, in std.math), what i wonder is the number for pi vs 2 letters. Unicode 03C0h, so now i have to convert that to decimal, code 960. Alt+960 = └ That's not pi... Looking up the symbol by itself in the character map was annoying enough. No, this is not a good idea unless it's easily accessible, preferably with 2 or fewer keystrokes to symbolize pi. As a reminder most of us are programmers, not scientists or mathematicians. Having specialized symbols won't give us any benefit. It's not like we're filling out a complex formula with college level math for a thesis. Didn't we have "pitching D to academia" thread recently? Honestly, any tool can be abused. Javascript, Swift and even partially Haskell allow unicode names and I'm sure we all saw that toy example that was full of emojis, but can you say it has been a problem in practice?
Re: Uniform Function Call Syntax?
On Monday, 7 March 2016 at 06:57:48 UTC, Ola Fosheim Grøstad wrote: immutable π = 3.14; Oh, the horror! With the assumption pi is declared elsewhere (say, in std.math), what i wonder is the number for pi vs 2 letters. Unicode 03C0h, so now i have to convert that to decimal, code 960. Alt+960 = └ That's not pi... Looking up the symbol by itself in the character map was annoying enough. No, this is not a good idea unless it's easily accessible, preferably with 2 or fewer keystrokes to symbolize pi. As a reminder most of us are programmers, not scientists or mathematicians. Having specialized symbols won't give us any benefit. It's not like we're filling out a complex formula with college level math for a thesis.
Re: Uniform Function Call Syntax?
On Monday, 7 March 2016 at 06:48:10 UTC, Era Scarecrow wrote: I'm reminded. Weren't there standard 50-something keyboards, and then 101 keyboards? And you actually COULDN'T do programming on the 50-key keyboards because literally standard symbols were missing? No unicode. No keys. No mouse. No bitmap graphics. Just a hardwired terminal. Welcome to the 60s and 70s. I have an excellent idea! I'll start programming using nothing but the greek alphabet, better yet unicode characters! immutable π = 3.14; writeln( ∑(values) ); x = x + ∆; Oh, the horror!
Re: Uniform Function Call Syntax?
On Monday, 7 March 2016 at 06:02:46 UTC, Patience wrote:
On Monday, 7 March 2016 at 00:19:07 UTC, Xinok wrote:
Please no. If I need to open up Character Map just to write
code, something has gone horribly wrong.
A proper code editor could handle this. Type something like
ctrl + ? and it pops up all the implemented uni-code operators.
Else we are stuck in the past until you decide to change...
I'm reminded. Weren't there standard 50-something keyboards, and
then 101 keyboards? And you actually COULDN'T do programming on
the 50-key keyboards because literally standard symbols were
missing?
Honestly it would be annoying to have to pull up character map,
memorize ascii or unicode characters, or even require a helper
program which isn't present on most tools.
I have an excellent idea! I'll start programming using nothing
but the greek alphabet, better yet unicode characters!
//謎機能
int æ(File ß, int Ɣ, int Ʊ) {
return Ɣ 乘 Ɣ 加 Ʊ 子 7;
}
Actually let's alias off the ints too because, we don't need
those.
//謎機能
數 æ(數 Ɣ, 數 Ʊ) {
return Ɣ 乘 Ɣ 加 Ʊ 子 7;
}
i happy i cut & paste everywhere (instead of relying on
standardized ascii characters that actually mean something to
me... Okay maybe this went off track)
Re: Uniform Function Call Syntax?
On Monday, 7 March 2016 at 00:19:07 UTC, Xinok wrote:
Please no. If I need to open up Character Map just to write
code, something has gone horribly wrong.
Modern languages support Unicode in names, so it is too late:
import std.stdio;
real Ø(real radius){ return 6.28*radius; }
void main()
{
writeln(Ø(3));
}
Re: Uniform Function Call Syntax?
On Monday, 7 March 2016 at 00:19:07 UTC, Xinok wrote: On Sunday, 6 March 2016 at 07:45:58 UTC, Ola Fosheim Grøstad wrote: I think it would be better idea to just add the ability to add unicode operators, and to avoid precedence issues one could just require them to use parentheses. That way you could define opCustom"•" and use it as: ( point1 • point2 ) Please no. If I need to open up Character Map just to write code, something has gone horribly wrong. A proper code editor could handle this. Type something like ctrl + ? and it pops up all the implemented uni-code operators. Else we are stuck in the past until you decide to change...
Re: Uniform Function Call Syntax?
On Sunday, 6 March 2016 at 07:45:58 UTC, Ola Fosheim Grøstad wrote: I think it would be better idea to just add the ability to add unicode operators, and to avoid precedence issues one could just require them to use parentheses. That way you could define opCustom"•" and use it as: ( point1 • point2 ) Please no. If I need to open up Character Map just to write code, something has gone horribly wrong.
Re: Uniform Function Call Syntax?
On Friday, 4 March 2016 at 01:56:34 UTC, user001 wrote: "dot". For mathematical purposes it is a lot easier to understand "dot(a, b)" than "a.dot(b)", at least in my opinion. Why don't you just define it as "dot(a,b)" to begin with? I think it would be better idea to just add the ability to add unicode operators, and to avoid precedence issues one could just require them to use parentheses. That way you could define opCustom"•" and use it as: ( point1 • point2 ) An often stated golden rule in language design is that there should be one way to do something. When you break that rule it often is due to a language design deficiency. UFCS in both D and C++ are hacks. IMO that makes things more confusing, not more clear.
Re: Uniform Function Call Syntax?
On 3/3/2016 5:56 PM, user001 wrote:
It may not add as much value but I think it'd be a bit better as now you no
longer have a global function with a simple name "dot". For mathematical
purposes it is a lot easier to understand "dot(a, b)" than "a.dot(b)", at least
in my opinion. Just curious that's all.
If that's how you want to call dot, add the following:
float dot(Vec3 a, Vec3 b) { return a.dot(b); }
Re: Uniform Function Call Syntax?
On Friday, 4 March 2016 at 02:09:25 UTC, Era Scarecrow wrote:
On Friday, 4 March 2016 at 01:56:34 UTC, user001 wrote:
Was just wondering why UFCS only works in one direction, that
is why functions can be used as if it were part of a
struct/class but not the other way around.
int dot;
float value = dot(a, b); // would be same as a.dot(b)
// doesn't try to use local "int dot"
Immediately looking at only that part of the code, i have to
ask 'how the hell are you calling the int???'. Of course i can
tell from your source dot is also a function in the vector.
Considering dot could now shadow the variables or function
names, it would quickly QUICKLY become annoying. A hierarchy of
how the call is used plus the documentation of what it's
obviously doing is a much better approach. Not to mention we've
been using . and -> and * so long for accessing/de-referencing
members that are attached so long that changing it is probably
not an option.
You can say the same thing about how it is currently implemented.
int[] arr = [ 0, 1, 2, 3 ];
static map(alias F)(int[])
{
}
writeln(arr.map!(a => a * 2)); // what does this mean array
doesnt have a map function, does it use the local map function or
the global one?
MAYBE if you were starting a language from scratch, but in this
case i would firmly say no, this is ugly and confusing.
Well it could possibly be happening with C++17 so it's not that
big of stretch to add it to an existing language, especially if
that language already has it half implemented.
Re: Uniform Function Call Syntax?
On Friday, 4 March 2016 at 01:56:34 UTC, user001 wrote: Was just wondering why UFCS only works in one direction, that is why functions can be used as if it were part of a struct/class but not the other way around. int dot; float value = dot(a, b); // would be same as a.dot(b) // doesn't try to use local "int dot" Immediately looking at only that part of the code, i have to ask 'how the hell are you calling the int???'. Of course i can tell from your source dot is also a function in the vector. Considering dot could now shadow the variables or function names, it would quickly QUICKLY become annoying. A hierarchy of how the call is used plus the documentation of what it's obviously doing is a much better approach. Not to mention we've been using . and -> and * so long for accessing/de-referencing members that are attached so long that changing it is probably not an option. MAYBE if you were starting a language from scratch, but in this case i would firmly say no, this is ugly and confusing.
Uniform Function Call Syntax?
Was just wondering why UFCS only works in one direction, that is
why functions can be used as if it were part of a struct/class
but not the other way around.
struct Vec3
{
float x;
float y;
float z;
float dot(Vec3 o)
{
return x * o.x + y * o.y + z * o.z;
}
}
int dot;
Vec3 a, b;
float value = dot(a, b); // would be same as a.dot(b)
// doesn't try to use local "int dot"
It may not add as much value but I think it'd be a bit better as
now you no longer have a global function with a simple name
"dot". For mathematical purposes it is a lot easier to understand
"dot(a, b)" than "a.dot(b)", at least in my opinion. Just curious
that's all.
Re: Making uniform function call syntax more complete a feature
"Simen Kjaeraas" , dans le message (digitalmars.D:172349), a écrit : > On Thu, 12 Jul 2012 16:31:34 +0200, Christophe Travert > wrote: > >> By the way, would it be possible to implement an opCmp that returns a >> double, to allow it to return a NaN ? That may allow to create values >> that are neither superior, nor inferior to other value, like NaNs. It's >> not possible to implement opCmp for a floating point comparison if opCmp >> is bound to return an int. > > Why don't you just test it? Not like it'd be many lines of code. > > Anyways, yes this works. Thanks. I don't always have a d compiler at hand when I read this newsgroup. Maybe I should just write myself a todo to make this kind of test back home rather than directly posting the idea.
Re: Making uniform function call syntax more complete a feature
On Thu, 12 Jul 2012 16:31:34 +0200, Christophe Travert wrote: By the way, would it be possible to implement an opCmp that returns a double, to allow it to return a NaN ? That may allow to create values that are neither superior, nor inferior to other value, like NaNs. It's not possible to implement opCmp for a floating point comparison if opCmp is bound to return an int. Why don't you just test it? Not like it'd be many lines of code. Anyways, yes this works. -- Simen
Re: Making uniform function call syntax more complete a feature
On Thursday, 12 July 2012 at 14:31:34 UTC, trav...@phare.normalesup.org (Christophe Travert) wrote: This behavior for opEquals is debatable, but make sense. I don't think it's debatable at all. You must be able to figure out how a class is going to behave just by looking at its definition.
Re: Making uniform function call syntax more complete a feature
"Thiez" , dans le message (digitalmars.D:172060), a écrit : >>> Have you considered adding operator overloading using UFCS >>> while you're at it? >> >> I assumed it's already possible to add operators >> non-intrusively, because operators are just syntactic sugar for >> method calls: >> >> ++var; // actual code >> var.opUnary!"++"(); // lowered once >> opUnary!"++"(var); // lowered twice (if necessary) >> >> If you're talking about overloading existing operators (which >> have been implemented as member functions) non-intrusively for >> other types, then I don't know, doesn't it work? > > I actually tried those yesterday (with opEquals and opCmp on > structs) and couldn't get it to work. Code still used what > appeared to be an automatically generated opEquals (that appears > to perform a bitwise comparison) instead of my UFCS opEquals. This behavior for opEquals is debatable, but make sense. If the designer of a struct did not implement opEquals, it may be that he intended opEqual to be the default opEqual. If you overload opEquals for such struct, you may be hijacking it's intended behavior: your not just adding a functionality, your overriding an existing functionality. Did you try operators that are not automatically generated ? > It's already quite obvious that the compiler does not obey its > own rewrite rules (see > http://dlang.org/operatoroverloading.html#compare) Consider opCmp: > a < b > is rewritten to > a.opCmp(b) < 0 > or > b.opCmp(a) > 0 > Let's assume the first rule is always chosen. According to the > very rewrite rule we just applied, this must be rewritten to > a.opCmp(b).opCmp(0) < 0 > > It seems quite obvious the compiler does not rewrite compares on > integers or all hell would break loose... The language reference > should be more specific about these things. The rewrite rule obviously apply only if the comparison operator is not already defined for those types by the langage. That could be precised in the web site, but it's consistent. By the way, would it be possible to implement an opCmp that returns a double, to allow it to return a NaN ? That may allow to create values that are neither superior, nor inferior to other value, like NaNs. It's not possible to implement opCmp for a floating point comparison if opCmp is bound to return an int. Another reason to ban Object imposing a specific signature for opCmp in all classes...
Re: Making uniform function call syntax more complete a feature
On Thursday, 12 July 2012 at 13:19:00 UTC, Thiez wrote: It's already quite obvious that the compiler does not obey its own rewrite rules (see http://dlang.org/operatoroverloading.html#compare) Consider opCmp: a < b is rewritten to a.opCmp(b) < 0 or b.opCmp(a) > 0 Let's assume the first rule is always chosen. According to the very rewrite rule we just applied, this must be rewritten to a.opCmp(b).opCmp(0) < 0 which must be rewritten to a.opCmp(b).opCmp(0).opCmp(0) < 0 and then a.opCmp(b).opCmp(0).opCmp(0).opCmp(0) < 0 and so on, to infinity. It seems quite obvious the compiler does not rewrite compares on integers or all hell would break loose... The language reference should be more specific about these things. Quote from 'The D Programming Language' chapter 12.1: "D’s approach to operator overloading is simple: whenever at least one participant in an operator expression is of user-defined type, the compiler rewrites the expression into a regular method call with a specific name. Then the regular language rules apply." So, assuming opCmp returns integer, then a.opCmp(b) < 0 doesn't get rewritten (lowered) any further, because user-defined types are not involved.
Re: Making uniform function call syntax more complete a feature
On Thursday, 12 July 2012 at 12:43:24 UTC, Tommi wrote: On Thursday, 12 July 2012 at 10:05:16 UTC, Thiez wrote: Have you considered adding operator overloading using UFCS while you're at it? I assumed it's already possible to add operators non-intrusively, because operators are just syntactic sugar for method calls: ++var; // actual code var.opUnary!"++"(); // lowered once opUnary!"++"(var); // lowered twice (if necessary) If you're talking about overloading existing operators (which have been implemented as member functions) non-intrusively for other types, then I don't know, doesn't it work? I actually tried those yesterday (with opEquals and opCmp on structs) and couldn't get it to work. Code still used what appeared to be an automatically generated opEquals (that appears to perform a bitwise comparison) instead of my UFCS opEquals. It's already quite obvious that the compiler does not obey its own rewrite rules (see http://dlang.org/operatoroverloading.html#compare) Consider opCmp: a < b is rewritten to a.opCmp(b) < 0 or b.opCmp(a) > 0 Let's assume the first rule is always chosen. According to the very rewrite rule we just applied, this must be rewritten to a.opCmp(b).opCmp(0) < 0 which must be rewritten to a.opCmp(b).opCmp(0).opCmp(0) < 0 and then a.opCmp(b).opCmp(0).opCmp(0).opCmp(0) < 0 and so on, to infinity. It seems quite obvious the compiler does not rewrite compares on integers or all hell would break loose... The language reference should be more specific about these things.
Re: Making uniform function call syntax more complete a feature
On Thursday, 12 July 2012 at 10:05:16 UTC, Thiez wrote: Have you considered adding operator overloading using UFCS while you're at it? I assumed it's already possible to add operators non-intrusively, because operators are just syntactic sugar for method calls: ++var; // actual code var.opUnary!"++"(); // lowered once opUnary!"++"(var); // lowered twice (if necessary) If you're talking about overloading existing operators (which have been implemented as member functions) non-intrusively for other types, then I don't know, doesn't it work?
Re: Making uniform function call syntax more complete a feature
On 07/12/2012 12:05 PM, Thiez wrote: Have you considered adding operator overloading using UFCS while you're at it? There is already an open issue about that iirc.
Re: Making uniform function call syntax more complete a feature
Have you considered adding operator overloading using UFCS while you're at it?
Re: Making uniform function call syntax more complete a feature
I posted this as an enhancement request over there: http://d.puremagic.com/issues/show_bug.cgi?id=8381
Re: Making uniform function call syntax more complete a feature
On 2012-06-17 08:39, Tommi wrote: As I see it, the goal of uniform function call syntax, as described here http://www.drdobbs.com/blogs/cpp/232700394, is to allow non-intrusively extending the functionality of a type. I think the current implementation comes short in accomplishing this goal on two accounts: 1) You can't non-intrusively add static member functions 2) You can't non-intrusively add constructors So, I'm suggesting these two features to be added to the language: 1. Static method lowering rules If function calls like the following are encountered... A) Type.compute(); B) Type.compute; // it's a static @property function ...and the compute functions haven't been implemented by Type, they get lowered into free function calls... A) compute!(Type)(); B) compute!(Type); 2. Constructors as free functions If a constructor call hasn't been implemented by Type... auto t = Type(); ...then it get's lowered into a free function call... auto t = this!(Type)(); (or something like that) I like that idea. -- /Jacob Carlborg
Making uniform function call syntax more complete a feature
As I see it, the goal of uniform function call syntax, as described here http://www.drdobbs.com/blogs/cpp/232700394, is to allow non-intrusively extending the functionality of a type. I think the current implementation comes short in accomplishing this goal on two accounts: 1) You can't non-intrusively add static member functions 2) You can't non-intrusively add constructors So, I'm suggesting these two features to be added to the language: 1. Static method lowering rules If function calls like the following are encountered... A) Type.compute(); B) Type.compute; // it's a static @property function ...and the compute functions haven't been implemented by Type, they get lowered into free function calls... A) compute!(Type)(); B) compute!(Type); 2. Constructors as free functions If a constructor call hasn't been implemented by Type... auto t = Type(); ...then it get's lowered into a free function call... auto t = this!(Type)(); (or something like that)
Re: Uniform Function Call Syntax(UFCS) and @property
On Monday, March 07, 2011 15:43:27 kenji hara wrote: > Necessary to realize useful UFCS is appropriate annotations. 'named > this first parameter' is low cost, cachy, and doesn't need ugly > annotation syntax like @UFCS. Using an attribute (whatever it would be) would be far more in keeping with how the rest of the language works. That's the sort of thing that attributes are _for_. - Jonathan M Davis
Re: Uniform Function Call Syntax(UFCS) and @property
Additional point in my opinion:
Calling UFCS-able annotated function by normal function call syntax is
still vaild.
But not annotatied function shouldn't be allowed with member-like call syntax.
void f(T)(T this, int n){...} // UFCS annotated
void g(T)(T x, int n){...}// do not UFCS annotated
struct Foo{}
Foo foo;
foo.f(10); // member-like syntax - ok
f(foo, 10); // normal call syntax - still ok - UNIFIED function call syntax.
//foo.g(10); // Invalid
g(foo, 10);// normal call syntax - ok
Kenji
Re: Uniform Function Call Syntax(UFCS) and @property
2011/3/8 Steven Schveighoffer :
> I'll give you an example. This assumes that the compiler silently prefers
> member functions over free ones.
>
> Say you are using a struct from a library you didn't write like this:
>
> struct Foo
> {
> int x;
> }
>
> And you want to read data into it.
>
> So you write your own function:
>
> void read(ref Foo f) { readf("%d", &f.x); }
>
> So now, you can write stuff like:
>
> Foo f;
> f.read();
>
> and things work great!
>
> But a few years later, the author of foo decides to add serialization to
> Foo, and does:
>
> struct Foo
> {
> int x;
> void read() { readf("%x", &f.x); }
> void write() { writef("%x", f.x); }
> }
>
> All of a sudden, all the code you had that did f.read() now calls the
> member, which does something subtly different.
On last version, f.read should be compile error. Foo.read forms a
single overload set, and module function forms another overload set.
The overlap generates error.
> An overload set is formed by a group of functions with the same name declared
> in the same scope.
http://www.digitalmars.com/d/2.0/hijack.html
This is the definition of overload set, therefore It is appropriate to
me that Foo.read and module function read form two overload set.
> If the ambiguity is simply flagged as an error by the compiler, by simply
> defining a function with the same name outside the class or struct, you can
> deny access to the member function.
>
> Following the above example, if my localized read(ref Foo f) is defined in a
> common library module, anyone who uses my code (but not my read function)
> now wants to use the new Foo.read member function, it always results in a
> compile error. In essence, there is actually no way to access that member
> unless you stop importing my module. Maybe I could care less that it's a
> problem you have, I've since changed all my code to read(f) instead of
> f.read() to workaround my problem.
>
> These problems allow either hijacking of a function, or denying an object
> it's basic ability to define new members that are specific to itself. For
> all this confusion and pain, I think it's not worth the benefit of being
> able to do f.read() vs. read(f).
Yes. In my opinnion, UFCS refuse hijacking based on overload set rule.
>>> With builtins, there is no conflict. You cannot define member functions
>>> for
>>> integers or for arrays, so the ambiguity is gone.
>>
>> Almost yes. (Builtin array has 'length' property. It may conflict
>> module function 'length'.)
>
> Yes, but those are builtin properties, disallowed from day 1. Essentially,
> there is no way for an ambiguity to 'creep' into the code, since you could
> never call your length function via arr.length().
Builtin property vs UFCS should generate error because it makes
overload set overlapping.
> std.stdio.writefln forwards *directly* to stdout.writefln. Boilerplate code
> like this should be inlined out. I see zero waste here.
>
> Actually, the way writefln works, I think you picked an example that would
> not be affected by UFCS. writefln without a File argument would still need
> to exist in order to select stdout as the destination.
>
> But in any case, the difference between calling a free function and a member
> is so small that there really is no gain. You want to define a function
> that works on multiple types? It works, you just have to call func(t, ...)
> instead of t.func(...). I'd rather keep member functions as members, and
> external functions as external functions, as it adds to the
> understanding/readability.
Sorry, it does not work exactly same.
In my opinion:
1. File will be changed with range based design.
2. writef/writefln may replace using formattedWrite.
Then, File and formatting output will be following code:
File f;// future: File will have output-range interface
f.formattedWrite("%s", ...); // UFCS <- formattedWrite(f, "%s", ...);
// f.writef("%s", ...); // naming may be replaced..?
This approach separate File I/O and string formatting preciously. And
`any` string output range can have formattedWrite/writef.
> And the potential for abuse grows.
>
> For example, this should probably work today (not tested):
>
> "%d".writefln(5);
>
> And with UFCS, I now have a slew of types which allow this kind of abuse.
This bad syntax should be refused. My first suggestion "Only the free
function its first parameter named 'this' can use with UFCS." achieve
this purpose.
I don't deny that the benefit of UFCS is only 'looks'. But natural
syntax has well worth for code reading. And UFCS is possible to add
'members' non-intrusive. If member name conflict occurs, overload set
rule make it an error.
Necessary to realize useful UFCS is appropriate annotations. 'named
this first parameter' is low cost, cachy, and doesn't need ugly
annotation syntax like @UFCS.
Kenji
Re: Uniform Function Call Syntax(UFCS) and @property
On Mon, 07 Mar 2011 13:28:26 -0500, kenji hara wrote:
The problem is when there is a conflict between an actual member
funtion,
and a free function which takes the type as its first argument.
Who wins? The obvious choice is the member function. But let's say the
member function is added to the type long after the external function
exists. People who have written code that uses the external function
via
UFCS all of a sudden are now calling the member function, without
warning.
This is a form of hijacking.
Why do you prefer module functions? It will be selected by UFCS only
when there is no member that has the same name in class/struct. It is
clear.
I'll give you an example. This assumes that the compiler silently prefers
member functions over free ones.
Say you are using a struct from a library you didn't write like this:
struct Foo
{
int x;
}
And you want to read data into it.
So you write your own function:
void read(ref Foo f) { readf("%d", &f.x); }
So now, you can write stuff like:
Foo f;
f.read();
and things work great!
But a few years later, the author of foo decides to add serialization to
Foo, and does:
struct Foo
{
int x;
void read() { readf("%x", &f.x); }
void write() { writef("%x", f.x); }
}
All of a sudden, all the code you had that did f.read() now calls the
member, which does something subtly different.
You could say an ambiguous case should be an error, but then someone is
able
to issue a sort of "denial of service" attack by simply defining a free
function which coincides with a member function.
I don't understand the meaning of "denial of service" what you say. Is
it causing compile error? It is same behavior with overload set
conflict.
If the ambiguity is simply flagged as an error by the compiler, by simply
defining a function with the same name outside the class or struct, you
can deny access to the member function.
Following the above example, if my localized read(ref Foo f) is defined in
a common library module, anyone who uses my code (but not my read
function) now wants to use the new Foo.read member function, it always
results in a compile error. In essence, there is actually no way to
access that member unless you stop importing my module. Maybe I could
care less that it's a problem you have, I've since changed all my code to
read(f) instead of f.read() to workaround my problem.
These problems allow either hijacking of a function, or denying an object
it's basic ability to define new members that are specific to itself. For
all this confusion and pain, I think it's not worth the benefit of being
able to do f.read() vs. read(f).
With builtins, there is no conflict. You cannot define member
functions for
integers or for arrays, so the ambiguity is gone.
Almost yes. (Builtin array has 'length' property. It may conflict
module function 'length'.)
Yes, but those are builtin properties, disallowed from day 1.
Essentially, there is no way for an ambiguity to 'creep' into the code,
since you could never call your length function via arr.length().
I see almost no benefit for having UFCS on classes and structs. It is
already possible to add member functions to those types, and the
difference
between x(y) and y.x() is extremely trivial. If anything, this makes
member
functions lose their specificity -- a member function is no longer
attributed to the struct or class, it can be defined anywhere.
UFCS is veri usuful. It reduce fat interfaces of class/struct, and
separate 'useful but surrounded operation' from core operations of the
object.
A simple example is std.stdio.File.writefln. This function does the
almost same job std.stdio.writefln. Correct UFCS will cut wastes like
this.
std.stdio.writefln forwards *directly* to stdout.writefln. Boilerplate
code like this should be inlined out. I see zero waste here.
Actually, the way writefln works, I think you picked an example that would
not be affected by UFCS. writefln without a File argument would still
need to exist in order to select stdout as the destination.
But in any case, the difference between calling a free function and a
member is so small that there really is no gain. You want to define a
function that works on multiple types? It works, you just have to call
func(t, ...) instead of t.func(...). I'd rather keep member functions as
members, and external functions as external functions, as it adds to the
understanding/readability.
And the potential for abuse grows.
For example, this should probably work today (not tested):
"%d".writefln(5);
And with UFCS, I now have a slew of types which allow this kind of abuse.
-Steve
Re: Uniform Function Call Syntax(UFCS) and @property
> The problem is when there is a conflict between an actual member funtion, > and a free function which takes the type as its first argument. > > Who wins? The obvious choice is the member function. But let's say the > member function is added to the type long after the external function > exists. People who have written code that uses the external function via > UFCS all of a sudden are now calling the member function, without warning. > This is a form of hijacking. Why do you prefer module functions? It will be selected by UFCS only when there is no member that has the same name in class/struct. It is clear. > You could say an ambiguous case should be an error, but then someone is able > to issue a sort of "denial of service" attack by simply defining a free > function which coincides with a member function. I don't understand the meaning of "denial of service" what you say. Is it causing compile error? It is same behavior with overload set conflict. > With builtins, there is no conflict. You cannot define member functions for > integers or for arrays, so the ambiguity is gone. Almost yes. (Builtin array has 'length' property. It may conflict module function 'length'.) > And let's also not forget the WTF factor of when you read code that uses a > UFCS function, where would be the first place you look for it? In the class > or struct. Probably, but it seems to me that it is the software design problem. > I see almost no benefit for having UFCS on classes and structs. It is > already possible to add member functions to those types, and the difference > between x(y) and y.x() is extremely trivial. If anything, this makes member > functions lose their specificity -- a member function is no longer > attributed to the struct or class, it can be defined anywhere. UFCS is veri usuful. It reduce fat interfaces of class/struct, and separate 'useful but surrounded operation' from core operations of the object. A simple example is std.stdio.File.writefln. This function does the almost same job std.stdio.writefln. Correct UFCS will cut wastes like this. Kenji
Re: Uniform Function Call Syntax(UFCS) and @property
On Sat, 05 Mar 2011 19:15:17 -0500, kenji hara wrote: 2011/3/4 Steven Schveighoffer : Also, keep in mind that I think UFCS should be restricted to builtins only (i.e. primitives + arrays, not AA's, since they map to a struct that can be customized in druntime). To provide multiple ways for one to add members to classes/structs causes huge ambiguity/hijacking issues. I think the ambiguity/hijacking will be resolved by overload set. You do? The problem is when there is a conflict between an actual member funtion, and a free function which takes the type as its first argument. Who wins? The obvious choice is the member function. But let's say the member function is added to the type long after the external function exists. People who have written code that uses the external function via UFCS all of a sudden are now calling the member function, without warning. This is a form of hijacking. You could say an ambiguous case should be an error, but then someone is able to issue a sort of "denial of service" attack by simply defining a free function which coincides with a member function. With builtins, there is no conflict. You cannot define member functions for integers or for arrays, so the ambiguity is gone. And let's also not forget the WTF factor of when you read code that uses a UFCS function, where would be the first place you look for it? In the class or struct. I see almost no benefit for having UFCS on classes and structs. It is already possible to add member functions to those types, and the difference between x(y) and y.x() is extremely trivial. If anything, this makes member functions lose their specificity -- a member function is no longer attributed to the struct or class, it can be defined anywhere. -Steve
Re: Uniform Function Call Syntax(UFCS) and @property
On Saturday 05 March 2011 16:59:35 kenji hara wrote: > 2011/3/6 Jonathan M Davis : > > It likely would be, but once you add in alias this and opDispatch, it > > gets rather complicated (I'm still not sure how alias this and > > opDispatch gets sorted out when there's a conflict between them). So, > > we're going to have to look at all of the various combinations of what > > could happen fairly carefully to be sure of what exactly the > > ramifications will be. > > In my opinion, UFCS should have low priority than member > variable/function/alias this/opDispatch. > UFCS is outermost level of name lookup. > (Speaking of adding, alias this may be preferred rather than opDispatch.) > > > Personally, I see little point to UFCS if it's just for primitive types. > > Calls such as 7.max(5) seem quite pointless to me. The only advantage is > > that templated code could treat primitive types exactly the same as > > user-defined types, but how often do you really have a function which > > could be called on any type which would be a member function of a > > user-defined type but a free function for primitive types? I don't think > > that I've _ever_ seen that. So, I see the benefit of UFCS with regards > > to primitives to be limited. If that's all that we're going to get out > > of it, I see no reason to complicate things by adding UFCS to the > > language. > > I also think that 7.max(5) quite pointless. But @property has similar > problem, because of current dmd implementation. Now @property has no > enforcement. > I think the function anotated with @property should be called with no > paren. E.g. member property "attribute" call with paren: obj.attribute() - > It's occurs serious semantic conflict. Eventually, it _will_ be enforced that @property functions be called without parens and that non-property functions be called _with_ parens, but that hasn't happened yet. And there are a number of bugs related to @property which should probably be sorted out _before_ that happens, or there's code which will become illegal to call, because you won't be able to call it with the property syntax in spite of the fact that you _have_ to (for instance, I believe that there are some problems with functions which return ref and are both setters and getters which have to be called with () to work at the moment). > UFCS has same circumstance. I want to prevent writing it (7.max(5)). > My suggestion that first parameter named 'this' provides information > enough to archives this purpose. Well, it's not really universal if it doesn't generally work for anything, rather than only specific functions, and I do _not_ want it to get overly complicated, so I definitely dislike the idea of having a parameter named this do it. That strikes me as being way to fragile and unclear a rule. _If_ we want to restrict UFCS in that way, then I think that we should simply add a new property (e.g. @UFCS or @universal) which enables it. That would be far clearer and require less in the way of special casing by the compiler. - Jonathan M Davis
Re: Uniform Function Call Syntax(UFCS) and @property
2011/3/6 Jonathan M Davis : > It likely would be, but once you add in alias this and opDispatch, it gets > rather complicated (I'm still not sure how alias this and opDispatch gets > sorted > out when there's a conflict between them). So, we're going to have to look at > all > of the various combinations of what could happen fairly carefully to be sure > of > what exactly the ramifications will be. In my opinion, UFCS should have low priority than member variable/function/alias this/opDispatch. UFCS is outermost level of name lookup. (Speaking of adding, alias this may be preferred rather than opDispatch.) > Personally, I see little point to UFCS if it's just for primitive types. Calls > such as 7.max(5) seem quite pointless to me. The only advantage is that > templated code could treat primitive types exactly the same as user-defined > types, but how often do you really have a function which could be called on > any > type which would be a member function of a user-defined type but a free > function > for primitive types? I don't think that I've _ever_ seen that. So, I see the > benefit of UFCS with regards to primitives to be limited. If that's all that > we're going to get out of it, I see no reason to complicate things by adding > UFCS to the language. I also think that 7.max(5) quite pointless. But @property has similar problem, because of current dmd implementation. Now @property has no enforcement. I think the function anotated with @property should be called with no paren. E.g. member property "attribute" call with paren: obj.attribute() - It's occurs serious semantic conflict. UFCS has same circumstance. I want to prevent writing it (7.max(5)). My suggestion that first parameter named 'this' provides information enough to archives this purpose. Kenji
Re: Uniform Function Call Syntax(UFCS) and @property
On Saturday 05 March 2011 16:15:17 kenji hara wrote: > 2011/3/4 Steven Schveighoffer : > > Also, keep in mind that I think UFCS should be restricted to builtins > > only (i.e. primitives + arrays, not AA's, since they map to a struct > > that can be customized in druntime). To provide multiple ways for one > > to add members to classes/structs causes huge ambiguity/hijacking > > issues. > > I think the ambiguity/hijacking will be resolved by overload set. > You do? It likely would be, but once you add in alias this and opDispatch, it gets rather complicated (I'm still not sure how alias this and opDispatch gets sorted out when there's a conflict between them). So, we're going to have to look at all of the various combinations of what could happen fairly carefully to be sure of what exactly the ramifications will be. Personally, I see little point to UFCS if it's just for primitive types. Calls such as 7.max(5) seem quite pointless to me. The only advantage is that templated code could treat primitive types exactly the same as user-defined types, but how often do you really have a function which could be called on any type which would be a member function of a user-defined type but a free function for primitive types? I don't think that I've _ever_ seen that. So, I see the benefit of UFCS with regards to primitives to be limited. If that's all that we're going to get out of it, I see no reason to complicate things by adding UFCS to the language. - Jonathan M Davis
Re: Uniform Function Call Syntax(UFCS) and @property
2011/3/4 Steven Schveighoffer : > Also, keep in mind that I think UFCS should be restricted to builtins only > (i.e. primitives + arrays, not AA's, since they map to a struct that can be > customized in druntime). To provide multiple ways for one to add members to > classes/structs causes huge ambiguity/hijacking issues. I think the ambiguity/hijacking will be resolved by overload set. You do? Kenji
Re: Uniform Function Call Syntax(UFCS) and @property
On 03/05/2011 03:50 AM, Michel Fortin wrote:
On 2011-03-04 13:04:59 -0500, Jim said:
Jonathan M Davis Wrote:
On Friday 04 March 2011 04:59:14 David Nadlinger wrote:
On 3/3/11 10:27 PM, Jonathan M Davis wrote:
I'd strongly argue that global/module properties make no sense. What are
they a property of? The module?
You could as well say: I'd strongly argue that global/module variables
make no sense. What are they a variable of? The module?
In my opinion, allowing global variables but not global properties just
creates yet another unneeded special case.
I see no special case or inconsistency. The original idea behind a property (as
I understand it) is to abstract member variables so that you can easily switch
between having a public member variable and having a public member function
without having to change code. The term property implies that it is a property
or attribute of whatever it's on. A global variable or a local variable or any
kind of variable not on a class or struct is free-floating and not a
property or
attribute of anything. How many languages which have properties have them on
_anything_ other than objects?
I was surprised that anyone would suggest that @property could be used on
anything other than a class or struct's member function. I strongly suspect
that
the main reason that anyone is thinking that way is because properties in D
grew
out of being able to call pretty much any old function without parens as
long as
it had no parameters instead of based on the concept of properties to begin
with
as it likely would have been in other languages.
- Jonathan M Davis
Let's talk about accessors instead of properties because we are talking about
the functions, right, not the storage per se?
@getter, @setter as proposed by Michel Fortin.
Actually, there's a big drawback in having separate @getter and @setter
attributes: grouping functions under one attribute declaration like this
becomes impractical:
@property {
int length();
void length(int);
int capacity();
void capacity(int);
}
This let me think at the actual functionality provided by the so-called
property feature. The following is more or less thinking out loud:
* An implicite getter allows
1. calling a method & running computations while letting think it's just
data member access. I find this bad. The good point is a change in
implementation, from data to method member, won't break code, *if and only if*
the new feature does not require any param (!). Even then, silently adding a
method call & possibly costly computation is imo bad.
2. Implementing a setter for 4.
* An implicite setter allows:
3. Implementing a getter for 1.
4. Performing effects which are a logical consequence of the data member
change. Eg "p.x = 1;" would actually /move/ p. I find this bad: there should be
a move method, and a read-only x data member.
* A getter without setter allows:
5. Read-only data members (to the price of language complication & a method
call).
Finally, I think what we actually need is a read-only qualifier for data
members. (E basta!)
Denis
--
_
vita es estrany
spir.wikidot.com
Re: Uniform Function Call Syntax(UFCS) and @property
On Friday 04 March 2011 18:50:59 Michel Fortin wrote:
> On 2011-03-04 13:04:59 -0500, Jim said:
> > Jonathan M Davis Wrote:
> >> On Friday 04 March 2011 04:59:14 David Nadlinger wrote:
> >>> On 3/3/11 10:27 PM, Jonathan M Davis wrote:
> I'd strongly argue that global/module properties make no sense. What
> are they a property of? The module?
> >>>
> >>> You could as well say: I'd strongly argue that global/module variables
> >>> make no sense. What are they a variable of? The module?
> >>>
> >>> In my opinion, allowing global variables but not global properties just
> >>> creates yet another unneeded special case.
> >>
> >> I see no special case or inconsistency. The original idea behind a
> >> property (as I understand it) is to abstract member variables so that
> >> you can easily switch between having a public member variable and
> >> having a public member function without having to change code. The term
> >> property implies that it is a property or attribute of whatever it's
> >> on. A global variable or a local variable or any kind of variable not
> >> on a class or struct is free-floating and not a property or
> >> attribute of anything. How many languages which have properties have
> >> them on _anything_ other than objects?
> >>
> >> I was surprised that anyone would suggest that @property could be used
> >> on anything other than a class or struct's member function. I strongly
> >> suspect that
> >> the main reason that anyone is thinking that way is because properties
> >> in D grew
> >> out of being able to call pretty much any old function without parens
> >> as long as
> >> it had no parameters instead of based on the concept of properties to
> >> begin with
> >> as it likely would have been in other languages.
> >>
> >> - Jonathan M Davis
> >
> > Let's talk about accessors instead of properties because we are talking
> > about the functions, right, not the storage per se?
> > @getter, @setter as proposed by Michel Fortin.
>
> Actually, there's a big drawback in having separate @getter and @setter
> attributes: grouping functions under one attribute declaration like
> this becomes impractical:
>
> @property {
> int length();
> void length(int);
>
> int capacity();
> void capacity(int);
> }
Personally, I don't find that to be any great loss. I've never liked the
ability
to apply attributes to functions in bulk like that. The only attributes that I
ever do that sort of thing with are private, protected, package, and public.
And
those I use : for.
Regardless, the other problem is functions like
@property auto ref front() {...}
They're both the getter and the setter thanks to the ref. So, unless it was
legal to mark such functions with both @getter and @setter, you'd need an
attribute for marking functions which were both.
- Jonathan M Davis
Re: Uniform Function Call Syntax(UFCS) and @property
On 2011-03-04 13:04:59 -0500, Jim said:
Jonathan M Davis Wrote:
On Friday 04 March 2011 04:59:14 David Nadlinger wrote:
On 3/3/11 10:27 PM, Jonathan M Davis wrote:
I'd strongly argue that global/module properties make no sense. What are
they a property of? The module?
You could as well say: I'd strongly argue that global/module variables
make no sense. What are they a variable of? The module?
In my opinion, allowing global variables but not global properties just
creates yet another unneeded special case.
I see no special case or inconsistency. The original idea behind a property (as
I understand it) is to abstract member variables so that you can easily switch
between having a public member variable and having a public member function
without having to change code. The term property implies that it is a property
or attribute of whatever it's on. A global variable or a local variable or any
kind of variable not on a class or struct is free-floating and not a
property or
attribute of anything. How many languages which have properties have them on
_anything_ other than objects?
I was surprised that anyone would suggest that @property could be used on
anything other than a class or struct's member function. I strongly
suspect that
the main reason that anyone is thinking that way is because properties
in D grew
out of being able to call pretty much any old function without parens
as long as
it had no parameters instead of based on the concept of properties to
begin with
as it likely would have been in other languages.
- Jonathan M Davis
Let's talk about accessors instead of properties because we are talking
about the functions, right, not the storage per se?
@getter, @setter as proposed by Michel Fortin.
Actually, there's a big drawback in having separate @getter and @setter
attributes: grouping functions under one attribute declaration like
this becomes impractical:
@property {
int length();
void length(int);
int capacity();
void capacity(int);
}
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: Uniform Function Call Syntax(UFCS) and @property
On 03/04/2011 06:26 PM, Michel Fortin wrote:
Another idea someone proposed (I can't find the exact post to give proper
credit) would be to allow having a parameter named 'this'. This would allow the
creation of non-member functions using the member syntax as with the Uniform
Function Call Syntax but without the "Uniform" part: only function specially
labeled this way would be eligible to the member call syntax. This would solve
our property problem, but is dependent on how UFCS is implemented.
Lua version (center on "add a new method"):
-- hand-baked Lua OO type
Point = {
this = function (p, coords)
point = {x=0, y=0}
for k,v in pairs(coords) do
point[k] = v
end
return setmetatable(point, Point)
end ,
__tostring = function (point)
return "Point(" .. point.x .. "," .. point.y .. ")"
end ,
}
Point.__call = Point.this
Point.__index = Point
setmetatable(Point, Point)
-- a point
point = Point {x=1, y=2}
print (point) --> Point(1,2)
-- add a new method
Point.move = function (point, offset)
point.x = point.x + offset.x
point.y = point.y + offset.y
end
-- applicate added method (special syntax ':')
point:move {x=3, y=4}
print (point) --> Point(4,6)
Denis
--
_
vita es estrany
spir.wikidot.com
Re: Uniform Function Call Syntax(UFCS) and @property
Jonathan M Davis Wrote: > On Friday 04 March 2011 04:59:14 David Nadlinger wrote: > > On 3/3/11 10:27 PM, Jonathan M Davis wrote: > > > I'd strongly argue that global/module properties make no sense. What are > > > they a property of? The module? > > > > You could as well say: I'd strongly argue that global/module variables > > make no sense. What are they a variable of? The module? > > > > In my opinion, allowing global variables but not global properties just > > creates yet another unneeded special case. > > I see no special case or inconsistency. The original idea behind a property > (as > I understand it) is to abstract member variables so that you can easily > switch > between having a public member variable and having a public member function > without having to change code. The term property implies that it is a > property > or attribute of whatever it's on. A global variable or a local variable or > any > kind of variable not on a class or struct is free-floating and not a property > or > attribute of anything. How many languages which have properties have them on > _anything_ other than objects? > > I was surprised that anyone would suggest that @property could be used on > anything other than a class or struct's member function. I strongly suspect > that > the main reason that anyone is thinking that way is because properties in D > grew > out of being able to call pretty much any old function without parens as long > as > it had no parameters instead of based on the concept of properties to begin > with > as it likely would have been in other languages. > > - Jonathan M Davis Let's talk about accessors instead of properties because we are talking about the functions, right, not the storage per se? @getter, @setter as proposed by Michel Fortin.
Re: Uniform Function Call Syntax(UFCS) and @property
On 2011-03-04 08:30:44 -0500, "Steven Schveighoffer" said: Note that there is only one (currently) ambiguous case, the case of a getter on an array or a setter on the module. A setter on an array cannot be confused with something else, as well as a getter for the module. What we need is a syntax to disambiguate. So essentially, we take the most common case, and declare that as the default. But if you define the property this way * then it becomes a property the other way. Perhaps instead of @property we should have had @getter and @setter. It's shorter to write and easier to disambiguate. It might be too late to change that however. Another idea someone proposed (I can't find the exact post to give proper credit) would be to allow having a parameter named 'this'. This would allow the creation of non-member functions using the member syntax as with the Uniform Function Call Syntax but without the "Uniform" part: only function specially labeled this way would be eligible to the member call syntax. This would solve our property problem, but is dependent on how UFCS is implemented. Disallowing global-scope properties isn't very appealing to me. I hear Jonathan's plea that the word "property" means a property *of* something, implying it should be a member, but I think it's hair splitting. D has always allowed properties at global scope, I see no reason to change that only because we used the perhaps-not-totally-appropriate word "property" to name such a concept. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Uniform Function Call Syntax(UFCS) and @property
On Friday 04 March 2011 04:59:14 David Nadlinger wrote: > On 3/3/11 10:27 PM, Jonathan M Davis wrote: > > I'd strongly argue that global/module properties make no sense. What are > > they a property of? The module? > > You could as well say: I'd strongly argue that global/module variables > make no sense. What are they a variable of? The module? > > In my opinion, allowing global variables but not global properties just > creates yet another unneeded special case. I see no special case or inconsistency. The original idea behind a property (as I understand it) is to abstract member variables so that you can easily switch between having a public member variable and having a public member function without having to change code. The term property implies that it is a property or attribute of whatever it's on. A global variable or a local variable or any kind of variable not on a class or struct is free-floating and not a property or attribute of anything. How many languages which have properties have them on _anything_ other than objects? I was surprised that anyone would suggest that @property could be used on anything other than a class or struct's member function. I strongly suspect that the main reason that anyone is thinking that way is because properties in D grew out of being able to call pretty much any old function without parens as long as it had no parameters instead of based on the concept of properties to begin with as it likely would have been in other languages. - Jonathan M Davis
Re: Uniform Function Call Syntax(UFCS) and @property
On Thu, 03 Mar 2011 18:03:48 -0500, Jonathan M Davis wrote: On Thursday, March 03, 2011 14:07:30 Steven Schveighoffer wrote: On Thu, 03 Mar 2011 16:56:45 -0500, Jonathan M Davis wrote: > Conceptually, a property makes no sense unless it's a property _of_ > something. This is your opinion, not fact. It is a property of the program/global namespace/module whatever you want to call it. Per the definition of the word property, a property must be property _of_ something. Anything else would violate the definition of the word (not that programming has ever held itself all that firmly to English definitions). You can certainly argue that a global property is a property of a module, at which point it _does_ make sense in the sense that it is then a property _of_ the module. However, I definitely think that that's pushing it. I was debating this assumption you have made in making your statement, not the statement itself. Sorry, I sometimes don't express myself very well. I'll try again: It is your opinion that modules or classes/structs do not qualify as entities to define properties on. Not a fact. I disagree completely, and have given several counter-cases. What do you say about the examples, such as the Singleton, or the cache variable I use in druntime? Regardless, I'd still argue that @property shouldn't be allowed at the module level as long as it's going to create ambiguities. And adding extra rules or syntax to make it unambiguous as Kenji is suggesting seems like overkill. I don't disagree that making syntax might be overkill. But making rules that are not consistent doesn't make sense either. If I have a place I can put a variable, I should be also able to put a property there. Note that there is only one (currently) ambiguous case, the case of a getter on an array or a setter on the module. A setter on an array cannot be confused with something else, as well as a getter for the module. What we need is a syntax to disambiguate. So essentially, we take the most common case, and declare that as the default. But if you define the property this way * then it becomes a property the other way. Also, keep in mind that I think UFCS should be restricted to builtins only (i.e. primitives + arrays, not AA's, since they map to a struct that can be customized in druntime). To provide multiple ways for one to add members to classes/structs causes huge ambiguity/hijacking issues. Just thought of this, I think this might be good enough: @property(out) denotes a getter on its single argument for functions that are at the module level and have one argument: * if the property is inside a class or struct, then properties with no args are always getters, properties with a single arg are always setters. * if the property is outside a class or struct, and it has no arguments, it's a module getter * if the property is outside a class or struct, and it has one argument, it's a module setter (use @property(out) to change it to a getter on the first argument) * if the property is outside a class or struct, and it has two arguments, it's a setter on the first argument, as long as that first argument supports UFCS. We could define @property(in) also, and allow the syntax everywhere, but I think nobody will ever use it in unambiguous cases. Other possibilities could be used inside the parens. -Steve
Re: Uniform Function Call Syntax(UFCS) and @property
On 3/3/11 10:27 PM, Jonathan M Davis wrote: I'd strongly argue that global/module properties make no sense. What are they a property of? The module? You could as well say: I'd strongly argue that global/module variables make no sense. What are they a variable of? The module? In my opinion, allowing global variables but not global properties just creates yet another unneeded special case. David
Re: Uniform Function Call Syntax(UFCS) and @property
On 3/4/11 1:44 PM, Jim wrote: […] So, what do you think about this translation? Although it is the same type of transformation, but I wouldn't call this @property because it isn't a property _of_ something. This isn't what @property is about, but describes uniform function call syntax. The @property annotation is just about being able to omit the parentheses on a parameterless function call and to pass in a single parameter via the equals sign. David
Re: Uniform Function Call Syntax(UFCS) and @property
Jonathan M Davis Wrote: > On Thursday 03 March 2011 21:44:20 kenji hara wrote: > > 2011/3/4 Jonathan M Davis : > > > On Thursday, March 03, 2011 14:07:30 Steven Schveighoffer wrote: > > >> On Thu, 03 Mar 2011 16:56:45 -0500, Jonathan M Davis > > >> > > >> > > >> wrote: > > >> > Conceptually, a property makes no sense unless it's a property _of_ > > >> > something. > > >> > > >> This is your opinion, not fact. It is a property of the program/global > > >> namespace/module whatever you want to call it. > > > > > > Per the definition of the word property, a property must be property _of_ > > > something. Anything else would violate the definition of the word (not > > > that programming has ever held itself all that firmly to English > > > definitions). You can certainly argue that a global property is a > > > property of a module, at which point it _does_ make sense in the sense > > > that it is then a property _of_ the module. > > > > > > However, I definitely think that that's pushing it. Modules are really > > > only organizational entities, not things that you deal with directly in > > > the code. And > > > > I can basically agree with you. But that reason can not limit the > > design of the module. > > Some of D users may consider a module as a singleton. We can't prohibit it. > > > > > if you have a "property" of a module, then it's more like treating > > > @property purely as an abstraction of a variable rather than really > > > being a property of something. At that point, I'd almost argue that the > > > annotation should have been @variable instead. > > > > I still have the opposite viewpoint with you. A "property" of a module > > should be annotated > > with @property. > > > > > Regardless, I'd still argue that @property shouldn't be allowed at the > > > module level as long as it's going to create ambiguities. And adding > > > extra rules or syntax to make it unambiguous as Kenji is suggesting > > > seems like overkill. > > > > Current @property annotation does not have enforcement. When this has > > been improved > > in the future, the way annotating this' on UFCS will be also necessary. > > Only if you allow functions which are "properties" of modules. > > - Jonathan M Davis This @property thing where: if(t.empty); is translated to if(empty(t)); looks a lot like reversed functional composition in mathematics where: fun.gun(); would be translated to gun(fun()); if fun: X -> Y and gun: Y -> Z (I say reversed because it's usually written in the other order, like this g ∘ f, that is g /circle/ f.) So, what do you think about this translation? Although it is the same type of transformation, but I wouldn't call this @property because it isn't a property _of_ something.
Re: Uniform Function Call Syntax(UFCS) and @property
On Thursday 03 March 2011 21:44:20 kenji hara wrote: > 2011/3/4 Jonathan M Davis : > > On Thursday, March 03, 2011 14:07:30 Steven Schveighoffer wrote: > >> On Thu, 03 Mar 2011 16:56:45 -0500, Jonathan M Davis > >> > >> > >> wrote: > >> > Conceptually, a property makes no sense unless it's a property _of_ > >> > something. > >> > >> This is your opinion, not fact. It is a property of the program/global > >> namespace/module whatever you want to call it. > > > > Per the definition of the word property, a property must be property _of_ > > something. Anything else would violate the definition of the word (not > > that programming has ever held itself all that firmly to English > > definitions). You can certainly argue that a global property is a > > property of a module, at which point it _does_ make sense in the sense > > that it is then a property _of_ the module. > > > > However, I definitely think that that's pushing it. Modules are really > > only organizational entities, not things that you deal with directly in > > the code. And > > I can basically agree with you. But that reason can not limit the > design of the module. > Some of D users may consider a module as a singleton. We can't prohibit it. > > > if you have a "property" of a module, then it's more like treating > > @property purely as an abstraction of a variable rather than really > > being a property of something. At that point, I'd almost argue that the > > annotation should have been @variable instead. > > I still have the opposite viewpoint with you. A "property" of a module > should be annotated > with @property. > > > Regardless, I'd still argue that @property shouldn't be allowed at the > > module level as long as it's going to create ambiguities. And adding > > extra rules or syntax to make it unambiguous as Kenji is suggesting > > seems like overkill. > > Current @property annotation does not have enforcement. When this has > been improved > in the future, the way annotating ’this' on UFCS will be also necessary. Only if you allow functions which are "properties" of modules. - Jonathan M Davis
Re: Uniform Function Call Syntax(UFCS) and @property
2011/3/4 Jonathan M Davis : > On Thursday, March 03, 2011 14:07:30 Steven Schveighoffer wrote: >> On Thu, 03 Mar 2011 16:56:45 -0500, Jonathan M Davis >> >> wrote: >> > Conceptually, a property makes no sense unless it's a property _of_ >> > something. >> >> This is your opinion, not fact. It is a property of the program/global >> namespace/module whatever you want to call it. > > Per the definition of the word property, a property must be property _of_ > something. Anything else would violate the definition of the word (not that > programming has ever held itself all that firmly to English definitions). You > can > certainly argue that a global property is a property of a module, at which > point > it _does_ make sense in the sense that it is then a property _of_ the module. > However, I definitely think that that's pushing it. Modules are really only > organizational entities, not things that you deal with directly in the code. > And I can basically agree with you. But that reason can not limit the design of the module. Some of D users may consider a module as a singleton. We can't prohibit it. > if you have a "property" of a module, then it's more like treating @property > purely as an abstraction of a variable rather than really being a property of > something. At that point, I'd almost argue that the annotation should have > been > @variable instead. I still have the opposite viewpoint with you. A "property" of a module should be annotated with @property. > Regardless, I'd still argue that @property shouldn't be allowed at the module > level as long as it's going to create ambiguities. And adding extra rules or > syntax to make it unambiguous as Kenji is suggesting seems like overkill. Current @property annotation does not have enforcement. When this has been improved in the future, the way annotating ’this' on UFCS will be also necessary. Thanks. Kenji
Re: Uniform Function Call Syntax(UFCS) and @property
On 03/03/2011 10:56 PM, Jonathan M Davis wrote: Conceptually, a property makes no sense unless it's a property _of_ something. I'd argue that C# (which has properties) doesn't have global properties, but it doesn't even have global variables. It doesn't have static (class) properties though. Regardless, while syntactically, it might be beneficial in rare cases to use property syntax with a global variable, it violates the concept. FWIW, numerous other languages which have properties in _this_ sense of the term only have them in classes (python, Eiffel...) Denis -- _ vita es estrany spir.wikidot.com
Re: Uniform Function Call Syntax(UFCS) and @property
On Thursday, March 03, 2011 14:07:30 Steven Schveighoffer wrote: > On Thu, 03 Mar 2011 16:56:45 -0500, Jonathan M Davis > > wrote: > > Conceptually, a property makes no sense unless it's a property _of_ > > something. > > This is your opinion, not fact. It is a property of the program/global > namespace/module whatever you want to call it. Per the definition of the word property, a property must be property _of_ something. Anything else would violate the definition of the word (not that programming has ever held itself all that firmly to English definitions). You can certainly argue that a global property is a property of a module, at which point it _does_ make sense in the sense that it is then a property _of_ the module. However, I definitely think that that's pushing it. Modules are really only organizational entities, not things that you deal with directly in the code. And if you have a "property" of a module, then it's more like treating @property purely as an abstraction of a variable rather than really being a property of something. At that point, I'd almost argue that the annotation should have been @variable instead. Regardless, I'd still argue that @property shouldn't be allowed at the module level as long as it's going to create ambiguities. And adding extra rules or syntax to make it unambiguous as Kenji is suggesting seems like overkill. > > I'd argue that C# (which has properties) doesn't have global properties, > > but it > > doesn't even have global variables. It doesn't have static (class) > > properties > > though. > > Yes it does. I've used them quite a bit. > > Quick search reveals: > > http://www.yoda.arachsys.com/csharp/singleton.html Okay, so I obviously haven't used C# enough. I stand corrected. - Jonathan M Davis
Re: Uniform Function Call Syntax(UFCS) and @property
On Thu, 03 Mar 2011 16:56:45 -0500, Jonathan M Davis wrote: Conceptually, a property makes no sense unless it's a property _of_ something. This is your opinion, not fact. It is a property of the program/global namespace/module whatever you want to call it. I'd argue that C# (which has properties) doesn't have global properties, but it doesn't even have global variables. It doesn't have static (class) properties though. Yes it does. I've used them quite a bit. Quick search reveals: http://www.yoda.arachsys.com/csharp/singleton.html -Steve
Re: Uniform Function Call Syntax(UFCS) and @property
On Thursday, March 03, 2011 13:44:18 Steven Schveighoffer wrote:
> On Thu, 03 Mar 2011 16:27:37 -0500, Jonathan M Davis
>
> wrote:
> > On Thursday, March 03, 2011 12:32:44 kenji hara wrote:
> >> It seems to me that you think only combination of member-variable like
> >> property and UFCS.
> >> My suggestion is consider global-variable like property as well.
> >>
> >> example:
> >> @property int global_var(){...} // getter, int n = global_var;
> >> @property void global_var(int n){...} // setter, global_var = 10;
> >>
> >> I think that global variable like setter function and member-variable
> >> like getter function occur ambiguity.
> >> Getter and Setter are the opposite meaning.
> >
> > I'd strongly argue that global/module properties make no sense. What are
> > they a
> > property of? The module? The whole idea with properties in the first
> > place was to
> > be an abstraction of member variables. And since you really shouldn't be
> > using
> > mutable global/module variables anyway, the benefit of such a "property"
> > is
> > already limited. And if they cause ambiguity (as they obviously do),
> > then that's
> > one more reason to disallow them.
>
> I think global properties are certainly valid. You can have a global
> field, why not a global property?
>
> The classic example is a singleton:
>
> class Singleton
> {
> private this() {} // disable public construction
> private Singleton _instance;
> @property public static Singleton instance() {if(!_instance) _instance
> = new Singleton; return _instance;}
> }
>
> Note that instance has no 'this' pointer. However, it obviously does not
> have the ambiguities of UFC properties. However, I find the statement
> that a property must be a member variable very incorrect.
>
> I am sure there are good use cases for global (TLS) variables that are
> properties. In fact, I use one in druntime. The LRU cache for array
> appending is a per-thread array, and it *must* be allocated outside any
> scannable location (not in TLS or GC heap). Therefore, I malloc it.
> However, I malloc it on the first append. But this is hidden by a
> property.
>
> The main reason for doing it this way is because originally it was stored
> in TLS as a fixed-size array. However, that meant any cached memory
> blocks that were appended to would be kept in memory by the cache. I used
> the fixed array directly in many places in the file, so the easiest change
> was to make it a property. It works quite well actually. If we can ever
> mark sections of TLS as non-scannable, then I can easily change it back
> from a property to a field.
>
> See
> https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifet
> ime.d#L382
Conceptually, a property makes no sense unless it's a property _of_ something.
I'd argue that C# (which has properties) doesn't have global properties, but it
doesn't even have global variables. It doesn't have static (class) properties
though. Regardless, while syntactically, it might be beneficial in rare cases
to
use property syntax with a global variable, it violates the concept.
So, I'm against the idea regardless, but if allowing global properties results
in ambiguities that would require additional syntax to make it work, then I'm
that much more opposed to allowing it.
- Jonathan M Davis
Re: Uniform Function Call Syntax(UFCS) and @property
On Thu, 03 Mar 2011 16:27:37 -0500, Jonathan M Davis
wrote:
On Thursday, March 03, 2011 12:32:44 kenji hara wrote:
It seems to me that you think only combination of member-variable like
property and UFCS.
My suggestion is consider global-variable like property as well.
example:
@property int global_var(){...} // getter, int n = global_var;
@property void global_var(int n){...} // setter, global_var = 10;
I think that global variable like setter function and member-variable
like getter function occur ambiguity.
Getter and Setter are the opposite meaning.
I'd strongly argue that global/module properties make no sense. What are
they a
property of? The module? The whole idea with properties in the first
place was to
be an abstraction of member variables. And since you really shouldn't be
using
mutable global/module variables anyway, the benefit of such a "property"
is
already limited. And if they cause ambiguity (as they obviously do),
then that's
one more reason to disallow them.
I think global properties are certainly valid. You can have a global
field, why not a global property?
The classic example is a singleton:
class Singleton
{
private this() {} // disable public construction
private Singleton _instance;
@property public static Singleton instance() {if(!_instance) _instance
= new Singleton; return _instance;}
}
Note that instance has no 'this' pointer. However, it obviously does not
have the ambiguities of UFC properties. However, I find the statement
that a property must be a member variable very incorrect.
I am sure there are good use cases for global (TLS) variables that are
properties. In fact, I use one in druntime. The LRU cache for array
appending is a per-thread array, and it *must* be allocated outside any
scannable location (not in TLS or GC heap). Therefore, I malloc it.
However, I malloc it on the first append. But this is hidden by a
property.
The main reason for doing it this way is because originally it was stored
in TLS as a fixed-size array. However, that meant any cached memory
blocks that were appended to would be kept in memory by the cache. I used
the fixed array directly in many places in the file, so the easiest change
was to make it a property. It works quite well actually. If we can ever
mark sections of TLS as non-scannable, then I can easily change it back
from a property to a field.
See
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d#L382
-Steve
Re: Uniform Function Call Syntax(UFCS) and @property
On Thursday, March 03, 2011 12:32:44 kenji hara wrote:
> It seems to me that you think only combination of member-variable like
> property and UFCS.
> My suggestion is consider global-variable like property as well.
> example:
> @property int global_var(){...} // getter, int n = global_var;
> @property void global_var(int n){...} // setter, global_var = 10;
>
> I think that global variable like setter function and member-variable
> like getter function occur ambiguity.
> Getter and Setter are the opposite meaning.
I'd strongly argue that global/module properties make no sense. What are they a
property of? The module? The whole idea with properties in the first place was
to
be an abstraction of member variables. And since you really shouldn't be using
mutable global/module variables anyway, the benefit of such a "property" is
already limited. And if they cause ambiguity (as they obviously do), then
that's
one more reason to disallow them.
Conceptually, I don't think that properties make any sense unless they're
properties of a type (be it a user-defined type, or an array, or some other
type
called with UFCS). A property is a property _of_ something, not just a random
variable. And from a practical point of view, allowing properties which aren't
on a type causes ambiguity, so they make that much _less_ sense.
If you disallow global/module "properties," then you don't need any special
syntax to deal with the problems that they might cause. They should just work.
I see no reason to allow global/module "properties" when they don't make sense
conceptually and they cause ambiguities if you try and allow them.
- Jonathan M Davis
Re: Uniform Function Call Syntax(UFCS) and @property
It seems to me that you think only combination of member-variable like
property and UFCS.
My suggestion is consider global-variable like property as well.
example:
@property int global_var(){...} // getter, int n = global_var;
@property void global_var(int n){...} // setter, global_var = 10;
I think that global variable like setter function and member-variable
like getter function occur ambiguity.
Getter and Setter are the opposite meaning.
Kenji
2011/3/4 Jonathan M Davis :
> On Thursday, March 03, 2011 09:14:36 kenji hara wrote:
>> Current D's property-like function call is too loose.
>> Under current rule, following both two statements being legal.
>> void f(int n){...}
>> f(10);
>> f = 10;
>>
>> If @property will separate these two syntax definitely, but UFCS will
>> introduce the ambiguity again:
>> // future code
>> @property void f(int n){}
>> f = 10;
>> 10.f;
>>
>> We also definitely separate 'this' value where UFCS is allowed.
>
> UFCS is supposed to be allowed _everywhere_, or it isn't universal, and if it
> isn't universal, I don't really such much point to it personally.
>
> And I don't see any real ambiguity in those functions even with UFCS. A module
> level function which returns void and takes only one parameter shouldn't be a
> legal property. A property function should be a function which operates _on_
> something. It's an abstraction for a member variable. So, a getter property
> on a
> user-defined type should return a value and take nothing and a setter
> property on
> a user-defined type should return void and take a single parameter. But a
> getter
> property which isn't a member function should return a value and take a single
> parameter which is the type which the property is on, and a setter property
> which is a setter function should return void and take two parameters - the
> type
> which the property is on and the value to set.
>
> As such, I see no ambiguity. What you're suggesting complicates things and
> restricts UFCS such that it isn't really all that useful. The whole point of
> UFCS is that it be universal.
>
> - Jonathan M Davis
>
Re: Uniform Function Call Syntax(UFCS) and @property
On Thursday, March 03, 2011 09:14:36 kenji hara wrote:
> Current D's property-like function call is too loose.
> Under current rule, following both two statements being legal.
> void f(int n){...}
> f(10);
> f = 10;
>
> If @property will separate these two syntax definitely, but UFCS will
> introduce the ambiguity again:
> // future code
> @property void f(int n){}
> f = 10;
> 10.f;
>
> We also definitely separate 'this' value where UFCS is allowed.
UFCS is supposed to be allowed _everywhere_, or it isn't universal, and if it
isn't universal, I don't really such much point to it personally.
And I don't see any real ambiguity in those functions even with UFCS. A module
level function which returns void and takes only one parameter shouldn't be a
legal property. A property function should be a function which operates _on_
something. It's an abstraction for a member variable. So, a getter property on
a
user-defined type should return a value and take nothing and a setter property
on
a user-defined type should return void and take a single parameter. But a
getter
property which isn't a member function should return a value and take a single
parameter which is the type which the property is on, and a setter property
which is a setter function should return void and take two parameters - the
type
which the property is on and the value to set.
As such, I see no ambiguity. What you're suggesting complicates things and
restricts UFCS such that it isn't really all that useful. The whole point of
UFCS is that it be universal.
- Jonathan M Davis
Re: Uniform Function Call Syntax(UFCS) and @property
Current D's property-like function call is too loose.
Under current rule, following both two statements being legal.
void f(int n){...}
f(10);
f = 10;
If @property will separate these two syntax definitely, but UFCS will
introduce the ambiguity again:
// future code
@property void f(int n){}
f = 10;
10.f;
We also definitely separate 'this' value where UFCS is allowed.
Kenji
2011/3/4 Jonathan M Davis :
> On Thursday 03 March 2011 01:52:09 kenji hara wrote:
>> The two semantics have no relation with each other.
>>
>> My idea is that we allow 'this' keyword as the first parameter of free
>> function:
>> T t;
>>
>> void method(T)(ref T this){...}
>> --> t.method();
>> void method(T, A...)(ref T this, A args){...}
>> --> t.method(arg1, arg2);
>>
>> @property bool empty(T)(ref T this){...}
>> --> if (t.empty){...}
>> @property void empty(T)(ref T this, bool f){...}
>> --> t.empty = true;
>>
>>
>> Do you think?
>
> Why use this like that? UFCS is supposed to work with any function just like
> using the member function call syntax works with arrays and any function -
> otherwise it's not universal. And I would expect @property to work without
> "this". The functions you list should work just fine with arrays without the
> use
> of the keyword "this" and without the first parameter being a ref. The same
> should be true for UFCS if it's ever implemented.
>
> - Jonathan M Davis
>
Re: Uniform Function Call Syntax(UFCS) and @property
On Thursday 03 March 2011 01:52:09 kenji hara wrote:
> The two semantics have no relation with each other.
>
> My idea is that we allow 'this' keyword as the first parameter of free
> function:
> T t;
>
> void method(T)(ref T this){...}
> --> t.method();
> void method(T, A...)(ref T this, A args){...}
> --> t.method(arg1, arg2);
>
> @property bool empty(T)(ref T this){...}
> --> if (t.empty){...}
> @property void empty(T)(ref T this, bool f){...}
> --> t.empty = true;
>
>
> Do you think?
Why use this like that? UFCS is supposed to work with any function just like
using the member function call syntax works with arrays and any function -
otherwise it's not universal. And I would expect @property to work without
"this". The functions you list should work just fine with arrays without the
use
of the keyword "this" and without the first parameter being a ref. The same
should be true for UFCS if it's ever implemented.
- Jonathan M Davis
Re: Uniform Function Call Syntax(UFCS) and @property
On 03/03/2011 10:52 AM, kenji hara wrote:
The two semantics have no relation with each other.
My idea is that we allow 'this' keyword as the first parameter of free function:
T t;
void method(T)(ref T this){...}
--> t.method();
void method(T, A...)(ref T this, A args){...}
--> t.method(arg1, arg2);
@property bool empty(T)(ref T this){...}
--> if (t.empty){...}
@property void empty(T)(ref T this, bool f){...}
--> t.empty = true;
Do you think?
This is about Lua's solution on the topic (except there is no 'this' keyword,
the object's name is free.)
Denis
--
_
vita es estrany
spir.wikidot.com
Uniform Function Call Syntax(UFCS) and @property
The two semantics have no relation with each other.
My idea is that we allow 'this' keyword as the first parameter of free function:
T t;
void method(T)(ref T this){...}
--> t.method();
void method(T, A...)(ref T this, A args){...}
--> t.method(arg1, arg2);
@property bool empty(T)(ref T this){...}
--> if (t.empty){...}
@property void empty(T)(ref T this, bool f){...}
--> t.empty = true;
Do you think?
Re: Uniform Function Call syntax for properties
On Thu, 14 Oct 2010 22:22:19 -0400, Steven Schveighoffer wrote: On Thu, 14 Oct 2010 20:28:45 -0400, Robert Jacques wrote: First, to avoid confusion, I'd like to separate inappropriate usage at the binary level from textual/syntax level. For example, casting, compile-time reflection and .tupleof are all ways to circumvent the fundamental restrictions of a library in order to achieve inappropriate binary access, while alias and 'with()' allow (harmless?) syntactical changes, changing a library's effective API. The decision between what is and isn't inappropriate syntax is generally made by either the language designer or by your project's style guide. Indeed, libraries that define extensive changes in a language's appropriate syntax are often referred to as being domain specific languages instead of a simple libraries, modules or packages. And part of the reason for this nomenclature change is that DSLs, unlike libraries, tend to compose poorly and require varying levels of programmer buy-in. This is one reason why none of the DSL/macro features implemented and/or proposed for D are pervasive; they all have a very specific and defined radius of comprehension and scope. as well you can rename anything you want. Hell, for most D projects you have the source, just rename it! But if you want your code to be readable, you should follow the convention that the author intended, because that's how everyone else will read it and understand it. Which brings us to the concept of methods behaving syntactically as fields. The three solutions put forth so far are: methods-as-properties, which allow methods to behave like methods or fields; @property, which force specific methods to behave only as fields; and the uniform access principle, which allows methods _and_ fields to behave like either methods or fields. Both MAP and UAP are language level syntax changes, while @property gives libraries pervasive DSL-lite abilities. The main advantages of MAP and UAP is that they allow the project team to better select a coding style that suites them. On the downside, neither MAP nor UAP are mainstream concepts, so it can take people time to adapt, and more coding style choice inevitably breeds more coding style wars (i.e. names_with_underscores vs CamelCase, csHangarian vbNotation, sVNs vs longVariableNames, etc.). @property, on the other hand, moves the coding style choice to the library author, which, on the plus side, is similar to how C# handles things. However, it forces the author to choose a single coding style, which may not be appropriate for all users for all time. (read: poor user buy-in) Worse, an author's style choice will enviably conflict with either the project's style guidelines or a second author's library, leading to user code which has to constantly change styles. (read: poor composition) And the composition problem only worsens for generic code. Couldn't disagree more. An API without appropriate function names == fail. And the call style is part of the function name, like it or not. People see x = y, they think field. People see x(y) they think function. No matter the camel casing, or spacing between parentheses, or prefixes to the function name, or whether the curly brace is on the next line or not. It amazes me how many times we have to go over this. I fully agree that the ability to define the acceptable syntactic usage is critical to avoiding confusion, I simply believe that putting that responsibility in that hands of a project's style guide provides the best consistency and is the most inclusive. Furthermore, I would point out that ultimately the author serves the user; they are his/her customer and good libraries don't unnecessarily restrict their users. Indeed, one of D's best feature is the collection of things, both great and small, that lets it get out of the way of the coding process. I want the *compiler* to tell me when I incorrectly used a property, not a style guide (which requires a person for interpretation). -Steve I think you have misunderstood something. It is partly my fault, as I used naming styles as an example. More pertinent examples would be function calls vs operator overloading, or prefix (= x y) vs infix (x = y) vs postfix (x y =) notation. These are issues which are normally the purview of the language designer. When the language designer opens up field / method syntax to programmer control, the assumption that x = y means fields ceases to be axiomatic and becomes a programming convention/style. Similarly, that x(y) indicates a function call can also become a programming convention/style. Other programming languages, for example Eiffel, have proven the usefulness of field/method styles other than those of the C-family. In fact Eiffel does not syntactically differentiate stored values (aka fields) from computed values (a
Re: Uniform Function Call syntax for properties
On Thu, 14 Oct 2010 20:28:45 -0400, Robert Jacques wrote: First, to avoid confusion, I'd like to separate inappropriate usage at the binary level from textual/syntax level. For example, casting, compile-time reflection and .tupleof are all ways to circumvent the fundamental restrictions of a library in order to achieve inappropriate binary access, while alias and 'with()' allow (harmless?) syntactical changes, changing a library's effective API. The decision between what is and isn't inappropriate syntax is generally made by either the language designer or by your project's style guide. Indeed, libraries that define extensive changes in a language's appropriate syntax are often referred to as being domain specific languages instead of a simple libraries, modules or packages. And part of the reason for this nomenclature change is that DSLs, unlike libraries, tend to compose poorly and require varying levels of programmer buy-in. This is one reason why none of the DSL/macro features implemented and/or proposed for D are pervasive; they all have a very specific and defined radius of comprehension and scope. as well you can rename anything you want. Hell, for most D projects you have the source, just rename it! But if you want your code to be readable, you should follow the convention that the author intended, because that's how everyone else will read it and understand it. Which brings us to the concept of methods behaving syntactically as fields. The three solutions put forth so far are: methods-as-properties, which allow methods to behave like methods or fields; @property, which force specific methods to behave only as fields; and the uniform access principle, which allows methods _and_ fields to behave like either methods or fields. Both MAP and UAP are language level syntax changes, while @property gives libraries pervasive DSL-lite abilities. The main advantages of MAP and UAP is that they allow the project team to better select a coding style that suites them. On the downside, neither MAP nor UAP are mainstream concepts, so it can take people time to adapt, and more coding style choice inevitably breeds more coding style wars (i.e. names_with_underscores vs CamelCase, csHangarian vbNotation, sVNs vs longVariableNames, etc.). @property, on the other hand, moves the coding style choice to the library author, which, on the plus side, is similar to how C# handles things. However, it forces the author to choose a single coding style, which may not be appropriate for all users for all time. (read: poor user buy-in) Worse, an author's style choice will enviably conflict with either the project's style guidelines or a second author's library, leading to user code which has to constantly change styles. (read: poor composition) And the composition problem only worsens for generic code. Couldn't disagree more. An API without appropriate function names == fail. And the call style is part of the function name, like it or not. People see x = y, they think field. People see x(y) they think function. No matter the camel casing, or spacing between parentheses, or prefixes to the function name, or whether the curly brace is on the next line or not. It amazes me how many times we have to go over this. I fully agree that the ability to define the acceptable syntactic usage is critical to avoiding confusion, I simply believe that putting that responsibility in that hands of a project's style guide provides the best consistency and is the most inclusive. Furthermore, I would point out that ultimately the author serves the user; they are his/her customer and good libraries don't unnecessarily restrict their users. Indeed, one of D's best feature is the collection of things, both great and small, that lets it get out of the way of the coding process. I want the *compiler* to tell me when I incorrectly used a property, not a style guide (which requires a person for interpretation). -Steve
Re: Uniform Function Call syntax for properties
On Thu, 14 Oct 2010 09:42:34 -0400, Steven Schveighoffer wrote: On Wed, 13 Oct 2010 20:57:54 -0400, Robert Jacques wrote: On Wed, 13 Oct 2010 14:34:14 -0400, Steven Schveighoffer wrote: Because then we are back to writeln = 42; -Steve :) I see that despite not valid code for what, over a year now?, writeln = 42 still persists. IMO, that's because the head squeaky wheel is not really fond of properties :) It will eventually be fixed. That said, how exactly are we back to the verb = value "problem"? Because you can use properties in ways they weren't meant to be used. Specifically, you can use a getter as a setter or vice versa. I admit it's not exactly the same problem, but it's a very similar issue. The rearrangement ambiguity was never the expressed reason for introducing @property. In fact, despite all the passionate posts about how wrong "verb = value" looks, it took a very specific syntax ambiguity with delegates/opCall to warrant language inclusion. And given the practical problems @property has been running into, it kinda makes me wish I had run across the uniform access principle (http://www.eiffel.com/general/column/2005/Sept_October.html) back during the debates. I must have said this a hundred thousand times. It has to do with the power of the author to define usage. When you let the user define usage, confusion ensues. To me, the delegate issue is a nice bonus, and if that's what pushed property acceptance over the edge, so be it. Without the restrictions, the author loses the power to define usage, and he resorts to creating more verbose language like getFoo instead of just foo. Welcome to Java. -Steve First, to avoid confusion, I'd like to separate inappropriate usage at the binary level from textual/syntax level. For example, casting, compile-time reflection and .tupleof are all ways to circumvent the fundamental restrictions of a library in order to achieve inappropriate binary access, while alias and 'with()' allow (harmless?) syntactical changes, changing a library's effective API. The decision between what is and isn't inappropriate syntax is generally made by either the language designer or by your project's style guide. Indeed, libraries that define extensive changes in a language's appropriate syntax are often referred to as being domain specific languages instead of a simple libraries, modules or packages. And part of the reason for this nomenclature change is that DSLs, unlike libraries, tend to compose poorly and require varying levels of programmer buy-in. This is one reason why none of the DSL/macro features implemented and/or proposed for D are pervasive; they all have a very specific and defined radius of comprehension and scope. Which brings us to the concept of methods behaving syntactically as fields. The three solutions put forth so far are: methods-as-properties, which allow methods to behave like methods or fields; @property, which force specific methods to behave only as fields; and the uniform access principle, which allows methods _and_ fields to behave like either methods or fields. Both MAP and UAP are language level syntax changes, while @property gives libraries pervasive DSL-lite abilities. The main advantages of MAP and UAP is that they allow the project team to better select a coding style that suites them. On the downside, neither MAP nor UAP are mainstream concepts, so it can take people time to adapt, and more coding style choice inevitably breeds more coding style wars (i.e. names_with_underscores vs CamelCase, csHangarian vbNotation, sVNs vs longVariableNames, etc.). @property, on the other hand, moves the coding style choice to the library author, which, on the plus side, is similar to how C# handles things. However, it forces the author to choose a single coding style, which may not be appropriate for all users for all time. (read: poor user buy-in) Worse, an author's style choice will enviably conflict with either the project's style guidelines or a second author's library, leading to user code which has to constantly change styles. (read: poor composition) And the composition problem only worsens for generic code. I fully agree that the ability to define the acceptable syntactic usage is critical to avoiding confusion, I simply believe that putting that responsibility in that hands of a project's style guide provides the best consistency and is the most inclusive. Furthermore, I would point out that ultimately the author serves the user; they are his/her customer and good libraries don't unnecessarily restrict their users. Indeed, one of D's best feature is the collection of things, both great and small, that lets it get out of the way of the coding process. BTW: That article on the uniform access principal has an interesting sidebar on how Eiffel satisfied two very different sets of programmer
Re: Uniform Function Call syntax for properties
On Wed, 13 Oct 2010 20:57:54 -0400, Robert Jacques wrote: On Wed, 13 Oct 2010 14:34:14 -0400, Steven Schveighoffer wrote: Because then we are back to writeln = 42; -Steve :) I see that despite not valid code for what, over a year now?, writeln = 42 still persists. IMO, that's because the head squeaky wheel is not really fond of properties :) It will eventually be fixed. That said, how exactly are we back to the verb = value "problem"? Because you can use properties in ways they weren't meant to be used. Specifically, you can use a getter as a setter or vice versa. I admit it's not exactly the same problem, but it's a very similar issue. The rearrangement ambiguity was never the expressed reason for introducing @property. In fact, despite all the passionate posts about how wrong "verb = value" looks, it took a very specific syntax ambiguity with delegates/opCall to warrant language inclusion. And given the practical problems @property has been running into, it kinda makes me wish I had run across the uniform access principle (http://www.eiffel.com/general/column/2005/Sept_October.html) back during the debates. I must have said this a hundred thousand times. It has to do with the power of the author to define usage. When you let the user define usage, confusion ensues. To me, the delegate issue is a nice bonus, and if that's what pushed property acceptance over the edge, so be it. Without the restrictions, the author loses the power to define usage, and he resorts to creating more verbose language like getFoo instead of just foo. Welcome to Java. -Steve
Re: Uniform Function Call syntax for properties
On Wed, 13 Oct 2010 14:34:14 -0400, Steven Schveighoffer wrote: On Sat, 09 Oct 2010 21:58:00 -0400, Robert Jacques wrote: On Sat, 09 Oct 2010 16:28:32 -0400, Denis Koroskin <2kor...@gmail.com> wrote: On Sun, 10 Oct 2010 00:09:23 +0400, Sean Kelly wrote: Andrei Alexandrescu wrote: On 10/8/10 7:55 CDT, Steven Schveighoffer wrote: Someone was asking about UFC syntax for properties on d.learn, and I realized, we have a huge ambiguity here. Given a function: @property int foo(int x) Is this a global setter or a getter on an int? Good question. Setter. Consider "a = b = c". I think you missed the point. Which of the two is it: int x = 42; auto y = x.foo(); // transformed into "auto y = foo(x);", getter or foo = 42; // transformed into "foo(42);", setter Both match. I agree that there is ambiguity here, but does it why does foo have to be only a getter or only a setter? Why can't it behave like either, depending on its implementation and use? Because then we are back to writeln = 42; -Steve :) I see that despite not valid code for what, over a year now?, writeln = 42 still persists. That said, how exactly are we back to the verb = value "problem"? The rearrangement ambiguity was never the expressed reason for introducing @property. In fact, despite all the passionate posts about how wrong "verb = value" looks, it took a very specific syntax ambiguity with delegates/opCall to warrant language inclusion. And given the practical problems @property has been running into, it kinda makes me wish I had run across the uniform access principle (http://www.eiffel.com/general/column/2005/Sept_October.html) back during the debates.
Re: Will uniform function call syntax apply to operator overloads?
On Tue, 12 Oct 2010 17:08:16 -0400, Peter Alexander
wrote:
In short, when UFC is working on all types, will this be possible:
Foo opBinary(string op)(Foo a, Foo b)
{
return ...;
}
Foo x, y;
Foo z = x + y;
My reasoning here is that x + y is supposedly sugar for
x.opBinary!("+")(y), so the free opBinary defined above could be chosen
as a pseudo member of Foo.
Will this be possible?
IMO it has to be. operators use a technique called lowering which
modifies the original to be as if you typed in the resulting syntax.
opBinary has no special qualities except that it is the target of the
lowering, so it should be interpreted like any other template function.
To answer others' questions of why you'd want to do something like this, a
non-member function has control over the signature of both operands.
Without an external function, at least one of the operands must be a valid
reference.
Note the new implementation of comparing two objects for equality, which
calls opEquals(o1, o2) instead of o1.opEquals(o2). This significantly
improves robustness of opEquals since comparing a null object to another
will not result in a segfault.
Despite all this, I feel we may want to reinvestigate how to prevent
operators from being hijacked. An operator is usually implemented with
intimate knowledge of the two types. This usually means being implemented
in the same module at least, if not as a member of the class/struct. I
wonder if the lowering could be modified to require that.
-Steve
Re: Uniform Function Call syntax for properties
On Sat, 09 Oct 2010 21:58:00 -0400, Robert Jacques wrote: On Sat, 09 Oct 2010 16:28:32 -0400, Denis Koroskin <2kor...@gmail.com> wrote: On Sun, 10 Oct 2010 00:09:23 +0400, Sean Kelly wrote: Andrei Alexandrescu wrote: On 10/8/10 7:55 CDT, Steven Schveighoffer wrote: Someone was asking about UFC syntax for properties on d.learn, and I realized, we have a huge ambiguity here. Given a function: @property int foo(int x) Is this a global setter or a getter on an int? Good question. Setter. Consider "a = b = c". I think you missed the point. Which of the two is it: int x = 42; auto y = x.foo(); // transformed into "auto y = foo(x);", getter or foo = 42; // transformed into "foo(42);", setter Both match. I agree that there is ambiguity here, but does it why does foo have to be only a getter or only a setter? Why can't it behave like either, depending on its implementation and use? Because then we are back to writeln = 42; -Steve
Re: Will uniform function call syntax apply to operator overloads?
Peter Alexander wrote: Yeah, I also think it should at least be discouraged. I cannot see any situations wherein allowing it would bring significant enough advantages to warrant its use. That said, I am willing to accept there may be such situations, and perhaps even that they should be allowed. Is that how you feel about UFC in general? No. I can't see how operator overloads should receive discriminatory treatment with respect to their UFC-ability. Nor do I, when thinking rationally. :p But over the years I've been presented with so much FUD over operator overloading, I don't feel entirely at ease with the possibility of adding operators to third-party data structures. I guess I should keep to my usual thoughts on this, though: stupid people will write stupid code, no matter the tools given, so if someone abuses operator overloading, just stay clear of their code. (and complain loudly if you can't) -- Simen
Re: Will uniform function call syntax apply to operator overloads?
Robert Jacques wrote:
Unknown, but unlikely given how UFC for arrays work today: neither
operator overloads nor templates are supported.
That is not completely true - the following compiles. Templates with
more than one required parameter however, doesn't.
void output( T )( T[] value ) {
writeln( value );
}
void main( ) {
auto s = "Hello, world!";
s.output;
}
As for the fact that operator overloads don't work, I believe that
is due to array ops, meaning it is not indicative of behavior of
other data types.
--
Simen
Re: Will uniform function call syntax apply to operator overloads?
On 13/10/10 1:32 AM, Simen kjaeraas wrote: Jonathan M Davis wrote: Personally, I do _not_ think that overloaded operators should work with uniform function syntax, if for no other reason than because it doesn't actually look like the uniform function syntax does. There is no . operator directly involved. And I don't see any real value in overloaded operators which aren't part of the type. Unlike C++, I don't think that we have any operators where having an overloaded operator function be a member function is a problem (the classic operators with that problem being >> and <<). Yeah, I also think it should at least be discouraged. I cannot see any situations wherein allowing it would bring significant enough advantages to warrant its use. That said, I am willing to accept there may be such situations, and perhaps even that they should be allowed. Is that how you feel about UFC in general? I can't see how operator overloads should receive discriminatory treatment with respect to their UFC-ability.
Re: Will uniform function call syntax apply to operator overloads?
On Tue, 12 Oct 2010 17:08:16 -0400, Peter Alexander
wrote:
In short, when UFC is working on all types, will this be possible:
Foo opBinary(string op)(Foo a, Foo b)
{
return ...;
}
Foo x, y;
Foo z = x + y;
My reasoning here is that x + y is supposedly sugar for
x.opBinary!("+")(y), so the free opBinary defined above could be chosen
as a pseudo member of Foo.
Will this be possible?
Unknown, but unlikely given how UFC for arrays work today: neither
operator overloads nor templates are supported.
Re: Will uniform function call syntax apply to operator overloads?
Jonathan M Davis wrote: That would depend on what order it did things. If it replaced a.func() with func(a) before it replaced a + b with a.opBinary!"+"(b), then it wouldn't be more work at all. It would just naturally not work. If, on the other hand, the overloaded operators were replaced first, then it could turn a.opBinary!"+"(b) into opBinary!"+"(a, b). True. I thought of it as a single step that does both, and repeatedly if necessary. Personally, I do _not_ think that overloaded operators should work with uniform function syntax, if for no other reason than because it doesn't actually look like the uniform function syntax does. There is no . operator directly involved. And I don't see any real value in overloaded operators which aren't part of the type. Unlike C++, I don't think that we have any operators where having an overloaded operator function be a member function is a problem (the classic operators with that problem being >> and <<). Yeah, I also think it should at least be discouraged. I cannot see any situations wherein allowing it would bring significant enough advantages to warrant its use. That said, I am willing to accept there may be such situations, and perhaps even that they should be allowed. -- Simen
Re: Will uniform function call syntax apply to operator overloads?
On 13/10/10 12:15 AM, Jonathan M Davis wrote: Personally, I do _not_ think that overloaded operators should work with uniform function syntax, if for no other reason than because it doesn't actually look like the uniform function syntax does. There is no . operator directly involved. And I don't see any real value in overloaded operators which aren't part of the type. Unlike C++, I don't think that we have any operators where having an overloaded operator function be a member function is a problem (the classic operators with that problem being>> and<<). - Jonathan M Davis The way I see things, one of the main purposes of uniform function call is so that you can extend structs/classes from 3rd party libraries (i.e. someone else has defined a class, and you want to add an operator without modifying the source file). If I can add any other member function using UFC, I don't see why I shouldn't be able to add operator overloads. It's just an unnecessary inconsistency not to allow them.
Re: Will uniform function call syntax apply to operator overloads?
On Tuesday, October 12, 2010 15:53:38 Simen kjaeraas wrote: > Tomek Sowiński wrote: > >> As long as operator overloading is defined the way it is, it should work > >> like that, yes. > > > > Funny. I remember asking this not too long ago and got no as an answer. > > > > :) > > I'm not saying it will. But as long as operator overloading is defined as > a rewrite of e.g. a + b => a.opBinary!"+"( b ), and uniform function call > syntax is defined as a rewrite of a.opBinary!"+"( b ) => > opBinary!"+"( a, b ), and there are no extra, special rules in play, I > would be surprised if it does not work. > > By this I mean, it would be anti-feature if it did not work, as the > compiler would have to be more complex to not support it than to support > it. That would depend on what order it did things. If it replaced a.func() with func(a) before it replaced a + b with a.opBinary!"+"(b), then it wouldn't be more work at all. It would just naturally not work. If, on the other hand, the overloaded operators were replaced first, then it could turn a.opBinary!"+"(b) into opBinary!"+"(a, b). However, I don't think that you can create freestanding operator overloads. As I understand it, they have to be part of a type (though I could be wrong). Assuming that that were the case, the uniform function syntax would be irrelevant because you couldn't legally declare an overloaded operator function which would work with it. Personally, I do _not_ think that overloaded operators should work with uniform function syntax, if for no other reason than because it doesn't actually look like the uniform function syntax does. There is no . operator directly involved. And I don't see any real value in overloaded operators which aren't part of the type. Unlike C++, I don't think that we have any operators where having an overloaded operator function be a member function is a problem (the classic operators with that problem being >> and <<). - Jonathan M Davis
Re: Will uniform function call syntax apply to operator overloads?
Tomek Sowiński wrote: As long as operator overloading is defined the way it is, it should work like that, yes. Funny. I remember asking this not too long ago and got no as an answer. :) I'm not saying it will. But as long as operator overloading is defined as a rewrite of e.g. a + b => a.opBinary!"+"( b ), and uniform function call syntax is defined as a rewrite of a.opBinary!"+"( b ) => opBinary!"+"( a, b ), and there are no extra, special rules in play, I would be surprised if it does not work. By this I mean, it would be anti-feature if it did not work, as the compiler would have to be more complex to not support it than to support it. -- Simen
Re: Will uniform function call syntax apply to operator overloads?
Simen kjaeraas napisał:
> Peter Alexander wrote:
>
>> In short, when UFC is working on all types, will this be possible:
>>
>> Foo opBinary(string op)(Foo a, Foo b)
>> {
>> return ...;
>> }
>>
>> Foo x, y;
>> Foo z = x + y;
>>
>> My reasoning here is that x + y is supposedly sugar for
>> x.opBinary!("+")(y), so the free opBinary defined above could be chosen
>> as a pseudo member of Foo.
>>
>> Will this be possible?
>
> As long as operator overloading is defined the way it is, it should work
> like that, yes.
Funny. I remember asking this not too long ago and got no as an answer. :)
Could someone from the D team take a stance on this?
--
Tomek
Re: Will uniform function call syntax apply to operator overloads?
Peter Alexander wrote:
In short, when UFC is working on all types, will this be possible:
Foo opBinary(string op)(Foo a, Foo b)
{
return ...;
}
Foo x, y;
Foo z = x + y;
My reasoning here is that x + y is supposedly sugar for
x.opBinary!("+")(y), so the free opBinary defined above could be chosen
as a pseudo member of Foo.
Will this be possible?
As long as operator overloading is defined the way it is, it should work
like that, yes.
--
Simen
Will uniform function call syntax apply to operator overloads?
In short, when UFC is working on all types, will this be possible:
Foo opBinary(string op)(Foo a, Foo b)
{
return ...;
}
Foo x, y;
Foo z = x + y;
My reasoning here is that x + y is supposedly sugar for
x.opBinary!("+")(y), so the free opBinary defined above could be chosen
as a pseudo member of Foo.
Will this be possible?
Re: Uniform Function Call syntax for properties
On Sun, 10 Oct 2010 00:58:39 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Sun, 10 Oct 2010 08:44:59 +0400, Robert Jacques
wrote:
On Sat, 09 Oct 2010 22:03:56 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Sun, 10 Oct 2010 05:58:00 +0400, Robert Jacques
wrote:
On Sat, 09 Oct 2010 16:28:32 -0400, Denis Koroskin
<2kor...@gmail.com> wrote:
On Sun, 10 Oct 2010 00:09:23 +0400, Sean Kelly
wrote:
Andrei Alexandrescu wrote:
On 10/8/10 7:55 CDT, Steven Schveighoffer wrote:
Someone was asking about UFC syntax for properties on d.learn,
and I
realized, we have a huge ambiguity here.
Given a function:
@property int foo(int x)
Is this a global setter or a getter on an int?
Good question.
Setter. Consider "a = b = c".
I think you missed the point. Which of the two is it:
int x = 42;
auto y = x.foo(); // transformed into "auto y = foo(x);", getter
or
foo = 42; // transformed into "foo(42);", setter
Both match.
I agree that there is ambiguity here, but does it why does foo have
to be only a getter or only a setter? Why can't it behave like
either, depending on its implementation and use?
Because you may want to have both, but you can't because their syntax
overlap.
Okay I'm confused. How do their syntax overlap? And which syntaxes do
you think are overlapping?
All the following 'lowerings' look fine/unambiguous to me:
foo = 42; => foo(42);
y = x.foo; => y = x.foo(); => y = foo(x);
foo = foo = x.foo; => foo = foo = x.foo(); => foo = foo = foo(x); =>
foo = foo(foo(x)); => foo(foo(foo(x)));
I wasn't talking about ambiguity. I told that you can't assign different
behavior to
foo = 42;
and
y = x.foo;
Both are resolving to the same symbol.
E.g. I'd like to write a setter, "foo = 42;":
private int _foo;
int foo(int x)
{
debug writeln("foo = ", x);
_foo = x;
return x;
}
But the following code also triggers the setter above:
y = 42.foo(); // prints "foo = 42;", sets private variable _foo to 42,
and returns that value
That's completely unexpected.
Actually, that's completely expected, in my humble opinion. Yes, it will
be a bit confusing to people new to D, perhaps even to those familiar with
C#'s extension methods. But once one understands the power and freedom of
UFC, that behavior is perfectly natural.
Imagine yourself writing class Foo with method bar, and a user who
highjacks a hole in the language, creates class bar, and invokes method
Foo on it. That's what it looks like at this moment.
Well, hijacking won't be possible since D's got really good function
hijacking detection. Also, how can Foo be both a method and a class?
Re: Uniform Function Call syntax for properties
On Sun, 10 Oct 2010 08:44:59 +0400, Robert Jacques
wrote:
On Sat, 09 Oct 2010 22:03:56 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Sun, 10 Oct 2010 05:58:00 +0400, Robert Jacques
wrote:
On Sat, 09 Oct 2010 16:28:32 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Sun, 10 Oct 2010 00:09:23 +0400, Sean Kelly
wrote:
Andrei Alexandrescu wrote:
On 10/8/10 7:55 CDT, Steven Schveighoffer wrote:
Someone was asking about UFC syntax for properties on d.learn, and
I
realized, we have a huge ambiguity here.
Given a function:
@property int foo(int x)
Is this a global setter or a getter on an int?
Good question.
Setter. Consider "a = b = c".
I think you missed the point. Which of the two is it:
int x = 42;
auto y = x.foo(); // transformed into "auto y = foo(x);", getter
or
foo = 42; // transformed into "foo(42);", setter
Both match.
I agree that there is ambiguity here, but does it why does foo have to
be only a getter or only a setter? Why can't it behave like either,
depending on its implementation and use?
Because you may want to have both, but you can't because their syntax
overlap.
Okay I'm confused. How do their syntax overlap? And which syntaxes do
you think are overlapping?
All the following 'lowerings' look fine/unambiguous to me:
foo = 42; => foo(42);
y = x.foo; => y = x.foo(); => y = foo(x);
foo = foo = x.foo; => foo = foo = x.foo(); => foo = foo = foo(x); => foo
= foo(foo(x)); => foo(foo(foo(x)));
I wasn't talking about ambiguity. I told that you can't assign different
behavior to
foo = 42;
and
y = x.foo;
Both are resolving to the same symbol.
E.g. I'd like to write a setter, "foo = 42;":
private int _foo;
int foo(int x)
{
debug writeln("foo = ", x);
_foo = x;
return x;
}
But the following code also triggers the setter above:
y = 42.foo(); // prints "foo = 42;", sets private variable _foo to 42, and
returns that value
That's completely unexpected. Imagine yourself writing class Foo with
method bar, and a user who highjacks a hole in the language, creates class
bar, and invokes method Foo on it. That's what it looks like at this
moment.
Re: Uniform Function Call syntax for properties
On Sat, 09 Oct 2010 22:03:56 -0400, Denis Koroskin <2kor...@gmail.com> wrote: On Sun, 10 Oct 2010 05:58:00 +0400, Robert Jacques wrote: On Sat, 09 Oct 2010 16:28:32 -0400, Denis Koroskin <2kor...@gmail.com> wrote: On Sun, 10 Oct 2010 00:09:23 +0400, Sean Kelly wrote: Andrei Alexandrescu wrote: On 10/8/10 7:55 CDT, Steven Schveighoffer wrote: Someone was asking about UFC syntax for properties on d.learn, and I realized, we have a huge ambiguity here. Given a function: @property int foo(int x) Is this a global setter or a getter on an int? Good question. Setter. Consider "a = b = c". I think you missed the point. Which of the two is it: int x = 42; auto y = x.foo(); // transformed into "auto y = foo(x);", getter or foo = 42; // transformed into "foo(42);", setter Both match. I agree that there is ambiguity here, but does it why does foo have to be only a getter or only a setter? Why can't it behave like either, depending on its implementation and use? Because you may want to have both, but you can't because their syntax overlap. Okay I'm confused. How do their syntax overlap? And which syntaxes do you think are overlapping? All the following 'lowerings' look fine/unambiguous to me: foo = 42; => foo(42); y = x.foo; => y = x.foo(); => y = foo(x); foo = foo = x.foo; => foo = foo = x.foo(); => foo = foo = foo(x); => foo = foo(foo(x)); => foo(foo(foo(x)));
Re: Uniform Function Call syntax for properties
On Sun, 10 Oct 2010 05:58:00 +0400, Robert Jacques wrote: On Sat, 09 Oct 2010 16:28:32 -0400, Denis Koroskin <2kor...@gmail.com> wrote: On Sun, 10 Oct 2010 00:09:23 +0400, Sean Kelly wrote: Andrei Alexandrescu wrote: On 10/8/10 7:55 CDT, Steven Schveighoffer wrote: Someone was asking about UFC syntax for properties on d.learn, and I realized, we have a huge ambiguity here. Given a function: @property int foo(int x) Is this a global setter or a getter on an int? Good question. Setter. Consider "a = b = c". I think you missed the point. Which of the two is it: int x = 42; auto y = x.foo(); // transformed into "auto y = foo(x);", getter or foo = 42; // transformed into "foo(42);", setter Both match. I agree that there is ambiguity here, but does it why does foo have to be only a getter or only a setter? Why can't it behave like either, depending on its implementation and use? Because you may want to have both, but you can't because their syntax overlap.
Re: Uniform Function Call syntax for properties
On Sat, 09 Oct 2010 16:28:32 -0400, Denis Koroskin <2kor...@gmail.com> wrote: On Sun, 10 Oct 2010 00:09:23 +0400, Sean Kelly wrote: Andrei Alexandrescu wrote: On 10/8/10 7:55 CDT, Steven Schveighoffer wrote: Someone was asking about UFC syntax for properties on d.learn, and I realized, we have a huge ambiguity here. Given a function: @property int foo(int x) Is this a global setter or a getter on an int? Good question. Setter. Consider "a = b = c". I think you missed the point. Which of the two is it: int x = 42; auto y = x.foo(); // transformed into "auto y = foo(x);", getter or foo = 42; // transformed into "foo(42);", setter Both match. I agree that there is ambiguity here, but does it why does foo have to be only a getter or only a setter? Why can't it behave like either, depending on its implementation and use?
Re: Uniform Function Call syntax for properties
On Sun, 10 Oct 2010 00:09:23 +0400, Sean Kelly wrote: Andrei Alexandrescu wrote: On 10/8/10 7:55 CDT, Steven Schveighoffer wrote: Someone was asking about UFC syntax for properties on d.learn, and I realized, we have a huge ambiguity here. Given a function: @property int foo(int x) Is this a global setter or a getter on an int? Good question. Setter. Consider "a = b = c". I think you missed the point. Which of the two is it: int x = 42; auto y = x.foo(); // transformed into "auto y = foo(x);", getter or foo = 42; // transformed into "foo(42);", setter Both match.
Re: Uniform Function Call syntax for properties
Andrei Alexandrescu wrote: > On 10/8/10 7:55 CDT, Steven Schveighoffer wrote: >> Someone was asking about UFC syntax for properties on d.learn, and I >> realized, we have a huge ambiguity here. >> >> Given a function: >> >> @property int foo(int x) >> >> Is this a global setter or a getter on an int? > > Good question. Setter. Consider "a = b = c".
Re: Uniform Function Call syntax for properties
On Sat, 09 Oct 2010 23:37:51 +0400, Andrei Alexandrescu wrote: On 10/9/10 13:33 CDT, Steven Schveighoffer wrote: On Fri, 08 Oct 2010 16:56:14 -0400, Nick Sabalausky wrote: Ugh, it seems D still doesn't quite understand the concept of a property. Here: @property int foo() // Obviously getter @property void foo(int x) // Obviously setter No other form makes any sence as a property. Frankly, I'm very surprised, and dissapointed, that anything else is even allowed. The only *possible* exception being: @property int foo(int x) // Combined getter/setter, if we decide that's needed It doesn't make any sense for a property getter to have a parameter (unless it's one parameter and it's used to set a new value). And it doesn't make any sence for a setter to have anthing other than exactly one parameter. Just disallow it. What could possibly be the point anyway? If it's got parameters it's a function call, not a variable. Property setters can have two parameters, one is the item used to set it, and one is the rvalue to use when setting. In objects, the first parameter is the hidden this parameter. With UFC, the parameter is explicit. Unless you feel builtin arrays should never have properties? The only exception are global properties which are not set on anything. And this is the problem. I think the syntax discussed in the other part of this thread is probably a good way to disambiguate the issues. -Steve One possibility is to simply say that @property int foo(T x); always means a getter for T. This is because if you want to define a global with getter and setter you can always write a type with assignment and alias this. Andrei I respectfully disagree. I strongly believe writing getters and setters should be a) consistent with each other and b) consistent with class/struct properties.
Re: Uniform Function Call syntax for properties
On 10/9/10 13:33 CDT, Steven Schveighoffer wrote: On Fri, 08 Oct 2010 16:56:14 -0400, Nick Sabalausky wrote: Ugh, it seems D still doesn't quite understand the concept of a property. Here: @property int foo() // Obviously getter @property void foo(int x) // Obviously setter No other form makes any sence as a property. Frankly, I'm very surprised, and dissapointed, that anything else is even allowed. The only *possible* exception being: @property int foo(int x) // Combined getter/setter, if we decide that's needed It doesn't make any sense for a property getter to have a parameter (unless it's one parameter and it's used to set a new value). And it doesn't make any sence for a setter to have anthing other than exactly one parameter. Just disallow it. What could possibly be the point anyway? If it's got parameters it's a function call, not a variable. Property setters can have two parameters, one is the item used to set it, and one is the rvalue to use when setting. In objects, the first parameter is the hidden this parameter. With UFC, the parameter is explicit. Unless you feel builtin arrays should never have properties? The only exception are global properties which are not set on anything. And this is the problem. I think the syntax discussed in the other part of this thread is probably a good way to disambiguate the issues. -Steve One possibility is to simply say that @property int foo(T x); always means a getter for T. This is because if you want to define a global with getter and setter you can always write a type with assignment and alias this. Andrei
