Re: Type helpers instead of UFCS
On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote: UFCS is good but there are two huge problems: - code completion in IDE. It'will never work. Is is possible. DCD plans to support it: https://github.com/Hackerpilot/DCD/issues/13 I agree that this is a big issue, though, and is one of the most important things to work on.
Re: Type helpers instead of UFCS
On Tuesday, 15 September 2015 at 16:14:39 UTC, John Colvin wrote: On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote: [...] How is this different to just having a specific type for the first argument? void writeln(Args...)(string s, Args args) { static import std.stdio; std.stdio.writeln(s, args); } Probably not much. Just forget this topic and let it fall into the black hole of memories...Already said previously that's probably not that a good idea.
Re: Type helpers instead of UFCS
On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote: UFCS is good but there are two huge problems: - code completion in IDE. It'will never work. - noobs, code is unreadable. That's why I propose the new keywords 'helper' and 'subject' that will allow to extend the properties pre-defined for a type, as long as the helper is imported: --- module myhelper; helper for subject : string { void writeln() { import std.stdio; writeln(subject); } } --- this will allow IDE plugins to provide better completion. for example if 'Peter' types --- void foo() { import myhelper; "foobarbaz". } --- after the dot, 'Peter' can get ".writeln". Why ? because a clear grammatical construction will allow an IDE plugin to work on a type and provides additional helpers that would be hard to put in the list without any specific grammatical construction. ... How is this different to just having a specific type for the first argument? void writeln(Args...)(string s, Args args) { static import std.stdio; std.stdio.writeln(s, args); }
Re: Type helpers instead of UFCS
On Saturday, 12 September 2015 at 20:50:01 UTC, BBasile wrote: On Saturday, 12 September 2015 at 20:40:35 UTC, Adam D. Ruppe wrote: On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote: - code completion in IDE. It'will never work. Why not? I haven't actually tried it, but it seems like a pretty easy problem, except perhaps with complex templates. - noobs, code is unreadable. meh meh too. It's "me"
Re: Type helpers instead of UFCS
On Saturday, 12 September 2015 at 21:04:47 UTC, BBasile wrote: You've got the idea. IDE plugins can not decently provide completion based on the UFCS possibilities. It's possible, just not implemented yet.
Re: Type helpers instead of UFCS
On Sunday, 13 September 2015 at 14:37:36 UTC, Kagamin wrote: On Saturday, 12 September 2015 at 21:04:47 UTC, BBasile wrote: You've got the idea. IDE plugins can not decently provide completion based on the UFCS possibilities. It's possible, just not implemented yet. Mono-d seems to have experimental UFCS support
Re: Type helpers instead of UFCS
On Sunday, 13 September 2015 at 17:17:18 UTC, bitwise wrote: On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote: UFCS is good but there are two huge problems: - code completion in IDE. It'will never work. By this do you mean completion will be flooded? If so, then +1. I would much prefer something like C# extension methods, but where the first argument has to be typed so that every random template UFC under the sun doesn't appear in completion. class Foo { void foo() {} } void bar(this Foo foo, int arg) { }// fine void baz(this T t) { }// compile error: first arg can't be a template void boo(Foo foo) // fine, but can't be used like a UFC int Main(string[] args) { Foo foo = new Foo(); foo.bar(1); // fine foo.baz(); // error, undefined method 'baz' boo(foo); // fine foo.boo(); // error, undefined method 'boo' } Yes this exactly what I meant. But a few hours after starting the topic i'm less excited about the feature. I was biased by the fact that i uniquely use DCD while there is of course also A.Bothe completion system and the default Visual D completion (don't know if it's been droped since the last time i used VD but there was setting to use Bothe's completion system in stead of VD's one).
Re: Type helpers instead of UFCS
On Sunday, 13 September 2015 at 17:23:25 UTC, BBasile wrote: On Sunday, 13 September 2015 at 17:17:18 UTC, bitwise wrote: On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote: [...] By this do you mean completion will be flooded? If so, then +1. I would much prefer something like C# extension methods, but where the first argument has to be typed so that every random template UFC under the sun doesn't appear in completion. class Foo { void foo() {} } void bar(this Foo foo, int arg) { }// fine void baz(this T t) { }// compile error: first arg can't be a template void boo(Foo foo) // fine, but can't be used like a UFC int Main(string[] args) { Foo foo = new Foo(); foo.bar(1); // fine foo.baz(); // error, undefined method 'baz' boo(foo); // fine foo.boo(); // error, undefined method 'boo' } Yes this exactly what I meant. But a few hours after starting the topic i'm less excited about the feature. I was biased by the fact that i uniquely use DCD while there is of course also A.Bothe completion system and the default Visual D completion (don't know if it's been droped since the last time i used VD but there was setting to use Bothe's completion system in stead of VD's one). Yea, I think this is one of those things that's just way to engrained in D to be changed. T* obj = cast(T*)malloc(sz); emplace(obj); obj.destroy(); // < this If things like this stopped working, I doubt if there's a D codebase in existence that wouldn't break =/ Bit
Re: Type helpers instead of UFCS
On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote: UFCS is good but there are two huge problems: - code completion in IDE. It'will never work. By this do you mean completion will be flooded? If so, then +1. I would much prefer something like C# extension methods, but where the first argument has to be typed so that every random template UFC under the sun doesn't appear in completion. class Foo { void foo() {} } void bar(this Foo foo, int arg) { }// fine void baz(this T t) { }// compile error: first arg can't be a template void boo(Foo foo) // fine, but can't be used like a UFC int Main(string[] args) { Foo foo = new Foo(); foo.bar(1); // fine foo.baz(); // error, undefined method 'baz' boo(foo); // fine foo.boo(); // error, undefined method 'boo' }
Re: Type helpers instead of UFCS
On Saturday, 12 September 2015 at 20:54:09 UTC, Enamex wrote: On Saturday, 12 September 2015 at 20:40:35 UTC, Adam D. Ruppe wrote: On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote: - code completion in IDE. It'will never work. Why not? I haven't actually tried it, but it seems like a pretty easy problem, except perhaps with complex templates. - noobs, code is unreadable. meh [...] With a dedicated syntax, specific functions/groups-of-functions could be easily recognized as extensions of a type and could even be made to be recognized by templates You've got the idea. IDE plugins can not decently provide completion based on the UFCS possibilities. With something like a type helper, it's more likely to work.
Re: Type helpers instead of UFCS
On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote: - code completion in IDE. It'will never work. Why not? I haven't actually tried it, but it seems like a pretty easy problem, except perhaps with complex templates. - noobs, code is unreadable. meh
Re: Type helpers instead of UFCS
On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote: That's why I propose the new keywords 'helper' and 'subject' that will allow to extend the properties pre-defined for a type, as long as the helper is imported: --- module myhelper; helper for subject : string Do we really need a 3-keyword chain? What's wrong with a simple `helper : string` or `helper(string)`? { void writeln() { import std.stdio; writeln(subject); } } --- Why `subject` to refer to the string the function gets called on? What's wrong with good old `this`, which is used for this purpose everywhere else?
Re: Type helpers instead of UFCS
On Saturday, 12 September 2015 at 20:40:35 UTC, Adam D. Ruppe wrote: On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote: - code completion in IDE. It'will never work. Why not? I haven't actually tried it, but it seems like a pretty easy problem, except perhaps with complex templates. - noobs, code is unreadable. meh meh too.
Re: Type helpers instead of UFCS
On Saturday, 12 September 2015 at 20:40:35 UTC, Adam D. Ruppe wrote: On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote: - code completion in IDE. It'will never work. Why not? I haven't actually tried it, but it seems like a pretty easy problem, except perhaps with complex templates. - noobs, code is unreadable. meh There's the bigger problem that extending a type via UFCS is 'open'; there can always be more functions where the first parameter accepts that type you're using. With a dedicated syntax, specific functions/groups-of-functions could be easily recognized as extensions of a type and could even be made to be recognized by templates (when the type is passed as type parameter or alias param) even though they're not in its definition. Kinda like type classes. But, anyway...
Re: Type helpers instead of UFCS
On Saturday, 12 September 2015 at 22:44:41 UTC, Idan Arye wrote: On Saturday, 12 September 2015 at 20:37:37 UTC, BBasile wrote: That's why I propose the new keywords 'helper' and 'subject' that will allow to extend the properties pre-defined for a type, as long as the helper is imported: --- module myhelper; helper for subject : string Do we really need a 3-keyword chain? What's wrong with a simple `helper : string` or `helper(string)`? { void writeln() { import std.stdio; writeln(subject); } } --- Why `subject` to refer to the string the function gets called on? What's wrong with good old `this`, which is used for this purpose everywhere else? no 'helper' is enough: http://www.israpresse.net/wp-content/uploads/2015/05/625088-34.jpg