Re: wrap/unwrap vs Go-style duck typing
On 31/10/13 05:35, Jonathan M Davis wrote: On Saturday, October 26, 2013 08:09:13 Andrei Alexandrescu wrote: Also, is it correct that Linux dynamic library support is really starting with this release? There was some before but not quite usable. It was there in 2.063, but we explicitly decided not to announce it due to how alpha it was. So, it makes some sense to say that it's new in this release, though I don't know how ready it is even now. How ready is it vis-à-vis other compilers? I remember reading that the dynamic library support was DMD-only.
Re: wrap/unwrap vs Go-style duck typing
On Saturday, October 26, 2013 08:09:13 Andrei Alexandrescu wrote: > Also, is it correct that Linux dynamic library support is really > starting with this release? There was some before but not quite usable. It was there in 2.063, but we explicitly decided not to announce it due to how alpha it was. So, it makes some sense to say that it's new in this release, though I don't know how ready it is even now. I haven't been paying a lot of attention, but it's my impression from what I've read that it still needs a lot of work. I expect that it's plenty ready for folks to play around with, but if it's anyone's expectation that it's finished as-is, then I expect that they'll be in for a rude surprise, and I don't know how many of those changes risk being non-backwards compatible. Martin would really be the one to ask about all that though, since he's the one doing most of the work. But we are getting there, regardless of whether it's really ready yet in this release or not. - Jonathan M Davis
Re: wrap/unwrap vs Go-style duck typing
On Friday, 25 October 2013 at 05:45:53 UTC, Andrei Alexandrescu wrote: Hello, I was curious how our fledgling wrap and unwrap routines compare with Go's duck typing - similarities, distinctions, performance. Please share any thoughts, thanks! Andrei It may have been really good if it worked with structs and could have been decently optimized away by compiler. Right now though similar built-in language implementation in Rust (I don't know how it is in go but assume similarity) is totally superior. Key point of this feature for me is being able to adapt existing non-polymorphic duck-typed aggregates (structs) to some external polymorphic binary interfaces. `wrap` does not seem to help here.
Re: wrap/unwrap vs Go-style duck typing
On Sunday, 27 October 2013 at 11:49:38 UTC, David Nadlinger wrote: If we want to mention shared library support in the release notes, I think we really ought to make clear (with a big red warning) that D doesn't make any guarantees about ABI stability right now. Also, there is the big unresolved topic of symbol visibility, see e.g. http://wiki.dlang.org/DIP45 and the associated discussion. I'm afraid we will repeat C++'s mistakes here and shoot ourselves in the foot big time if we keep symbols visible (i.e. exported from shared libraries) by default. The impact of that on (link time) optimization opportunities and, for big libraries, load times is absolutely non-negligible. David
Re: wrap/unwrap vs Go-style duck typing
On 2013-10-26 17:09, Andrei Alexandrescu wrote: Also, is it correct that Linux dynamic library support is really starting with this release? There was some before but not quite usable. Yes, I think so. In the current release you can statically link with a dynamic library written in D. In the upcoming release dlopen and similar functions should work. There's just a couple of regressions delaying the release. -- /Jacob Carlborg
Re: wrap/unwrap vs Go-style duck typing
On Sunday, 27 October 2013 at 10:25:02 UTC, Jacob Carlborg wrote: On 2013-10-26 17:09, Andrei Alexandrescu wrote: Also, is it correct that Linux dynamic library support is really starting with this release? There was some before but not quite usable. Yes, I think so. In the current release you can statically link with a dynamic library written in D. In the upcoming release dlopen and similar functions should work. There's just a couple of regressions delaying the release. If we want to mention shared library support in the release notes, I think we really ought to make clear (with a big red warning) that D doesn't make any guarantees about ABI stability right now. David
Re: wrap/unwrap vs Go-style duck typing
On Friday, 25 October 2013 at 05:45:53 UTC, Andrei Alexandrescu
wrote:
Hello,
I was curious how our fledgling wrap and unwrap routines
compare with Go's duck typing - similarities, distinctions,
performance. Please share any thoughts, thanks!
Andrei
This is what I've come up with.
It doesn't look like it works with structures? Go doesn't have
classes so structures are going to provide the most "Go" like
feel.
I expect it doesn't work with pseudo members. Go adds methods to
a struct similar to C++ friend methods or the UFCS provided by D.
Thus, it would feel more natural to a Go programmer to add
"friend" functions and expect them to be usable by the
typecons.wrap(). And on a D related note:
It would be nice to support UFCS during the wrapping, this comes
back to the example of arrays. An array is only a range because
std.range was imported, if a function checks to see
if(isInputRange!R) then arrays would fail if that same module
didn't import std.range. If wrap worked with the current scoped
"friend" functions, then the caller could easily just
arr.wrap!InputRange and move on. This just seems like the main D
use-case for this type of feature.
I'm also not sure why this code is giving me linker errors. I've
gotten the examples to work, but trying to mimic a Go blog isn't
working:
http://blog.jessta.id.au/2011/06/golang-interfaces.html
interface Writer { void Write(string); }
void SomeFunction(Writer w){
w.Write("pizza");
}
class Human {
void Write(string s) {
import std.stdio;
writeln(s);
}
}
void main() {
Human h = new Human();;
import std.typecons;
SomeFunction(h.wrap!Writer);
}
undefined reference to
`_D3std8typecons24__T4wrapTC5write6WriterZ23__T4wrapTC5write5HumanZ4Impl308__T8mixinAllVAyaa143_6f766572726964652052657475726e5479706521...
Re: wrap/unwrap vs Go-style duck typing
On Saturday, 26 October 2013 at 15:08:23 UTC, Andrei Alexandrescu wrote: On 10/26/13 7:55 AM, Nicolas Sicard wrote: On Saturday, 26 October 2013 at 14:39:31 UTC, Martin Nowak wrote: On 10/25/2013 07:46 AM, Andrei Alexandrescu wrote: Hello, I was curious how our fledgling wrap and unwrap routines compare with Go's duck typing - similarities, distinctions, performance. Please share any thoughts, thanks! I wonder whether specifying "Go-style wrap/unwrap" would be a fair characterization when announcing 2.064. Since Go's "duck typing" is implicit and automatic, and highlighted as such, "Go-style wrap/unwrap" sounds a bit paradoxical... What about "wrap/unwrap for Go-style structural typing"? Nicolas
Re: wrap/unwrap vs Go-style duck typing
On 10/26/13 7:55 AM, Nicolas Sicard wrote: On Saturday, 26 October 2013 at 14:39:31 UTC, Martin Nowak wrote: On 10/25/2013 07:46 AM, Andrei Alexandrescu wrote: Hello, I was curious how our fledgling wrap and unwrap routines compare with Go's duck typing - similarities, distinctions, performance. Please share any thoughts, thanks! Andrei What are you referring to by wrap/unwrap, functions like inputRangeObject? Martin http://dlang.org/phobos-prerelease/std_typecons.html#.wrap http://dlang.org/phobos-prerelease/std_typecons.html#.unwrap Yes, sorry for being unclear. I wonder whether specifying "Go-style wrap/unwrap" would be a fair characterization when announcing 2.064. Also, is it correct that Linux dynamic library support is really starting with this release? There was some before but not quite usable. Andrei
Re: wrap/unwrap vs Go-style duck typing
For the second example, can you pass x.wrap!(A, B) to functions expecting either A or B?
Re: wrap/unwrap vs Go-style duck typing
On Saturday, 26 October 2013 at 14:39:31 UTC, Martin Nowak wrote: On 10/25/2013 07:46 AM, Andrei Alexandrescu wrote: Hello, I was curious how our fledgling wrap and unwrap routines compare with Go's duck typing - similarities, distinctions, performance. Please share any thoughts, thanks! Andrei What are you referring to by wrap/unwrap, functions like inputRangeObject? Martin http://dlang.org/phobos-prerelease/std_typecons.html#.wrap http://dlang.org/phobos-prerelease/std_typecons.html#.unwrap
Re: wrap/unwrap vs Go-style duck typing
On 10/25/2013 07:46 AM, Andrei Alexandrescu wrote: Hello, I was curious how our fledgling wrap and unwrap routines compare with Go's duck typing - similarities, distinctions, performance. Please share any thoughts, thanks! Andrei What are you referring to by wrap/unwrap, functions like inputRangeObject? Martin
Re: wrap/unwrap vs Go-style duck typing
On Friday, 25 October 2013 at 05:45:53 UTC, Andrei Alexandrescu wrote: Hello, I was curious how our fledgling wrap and unwrap routines compare with Go's duck typing - similarities, distinctions, performance. Please share any thoughts, thanks! Andrei Are there some examples somewhere of when using wrap/unwrap is a good design choice? I can imagine it's convenient in some cases, but what's the "killer use".
wrap/unwrap vs Go-style duck typing
Hello, I was curious how our fledgling wrap and unwrap routines compare with Go's duck typing - similarities, distinctions, performance. Please share any thoughts, thanks! Andrei
Re: adapt the duck - round 3
On Tuesday, 14 May 2013 at 21:17:17 UTC, Jonathan M Davis wrote: http://d.puremagic.com/issues/show_bug.cgi?id=4999 https://github.com/D-Programming-Language/phobos/pull/1265 - Jonathan M Davis Thanks.
Re: adapt the duck - round 3
On Tuesday, May 14, 2013 20:02:53 Sebastian Graf wrote: > I was grinding through the forum for something like Kenji Hara's > adaptTo interfaces / structuralCast [1][2], purely at compile > time for structs in my specific case. > Those entries are all about 3 years old and I'm wondering why it > hasn't made it into Phobos yet. Was it only that we could not > find an appropriate name for it? > > > [1] > http://forum.dlang.org/thread/mailman.286.1285099532.858.digitalmars-d@purem > agic.com [2] > http://forum.dlang.org/thread/i9ae2n$k9g$1...@digitalmars.com?page=1 http://d.puremagic.com/issues/show_bug.cgi?id=4999 https://github.com/D-Programming-Language/phobos/pull/1265 - Jonathan M Davis
adapt the duck - round 3
I was grinding through the forum for something like Kenji Hara's adaptTo interfaces / structuralCast [1][2], purely at compile time for structs in my specific case. Those entries are all about 3 years old and I'm wondering why it hasn't made it into Phobos yet. Was it only that we could not find an appropriate name for it? [1] http://forum.dlang.org/thread/mailman.286.1285099532.858.digitalmar...@puremagic.com [2] http://forum.dlang.org/thread/i9ae2n$k9g$1...@digitalmars.com?page=1
Re: opDispatch, duck typing, and error messages
On 2011-04-24 01:39, Jonathan M Davis wrote: On 2011-04-22 01:54, Jonathan M Davis wrote: Jonathan M Davis wrote: I just checked. Exception _does_ take a default file and line number. Huh, maybe my dmd is getting old. Maybe we should revisit this after the next dmd release. Sounds like one is coming pretty soon with a lot of yummy goodness in it. All of this Exception stuff may be moot. It was in dmd 2.052. I don't know when the change was made though. I might have been the one to change it too. I made several changes a while back to make it so that Exception and Error types had default file and line numbers (and I actually had to remove several on various Errors, because the way that they're actually created makes them not work with default arguments). - Jonathan M Davis Ok It would nice to have file and line info available on Mac OS X as well. Whether there is file and line info with an exception should have nothing to do with the OS, except perhaps in some low-level stuff that druntime does, but I don't think that it makes a difference even then. Pretty much anything and everything derived from Exception should give a file and line number - generally that file and line number are the point where the exception was thrown from. Many Errors _can't_ have proper file and line numbers due to how they're thrown, though some of them (such as AssertError) should have proper file and line numbers. So, I don't know why you wouldn't be seeing file and line numbers on Mac OS X. It should be the same as the other OSes. Stack traces are another issue (and I have no idea if Mac OS X currenly has them), but the behavior with regards to file and line numbers in exceptions should be the same for all OSes. I don't know why they wouldn't be. - Jonathan M Davis Ok, I see that I was quite unclear. File and line info are available when an exception is thrown but not in the stack trace. If the stack trace uses the debug info then the problem is that the debug info segments are incorrectly named on Mac OS X. -- /Jacob Carlborg
Re: opDispatch, duck typing, and error messages
> On 2011-04-22 01:54, Jonathan M Davis wrote: > >> Jonathan M Davis wrote: > >>> I just checked. Exception _does_ take a default file and line number. > >> > >> Huh, maybe my dmd is getting old. > >> > >> Maybe we should revisit this after the next dmd release. Sounds like > >> one is coming pretty soon with a lot of yummy goodness in it. All > >> of this Exception stuff may be moot. > > > > It was in dmd 2.052. I don't know when the change was made though. I > > might have been the one to change it too. I made several changes a while > > back to make it so that Exception and Error types had default file and > > line numbers (and I actually had to remove several on various Errors, > > because the way that they're actually created makes them not work with > > default arguments). > > > > - Jonathan M Davis > > It would nice to have file and line info available on Mac OS X as well. Whether there is file and line info with an exception should have nothing to do with the OS, except perhaps in some low-level stuff that druntime does, but I don't think that it makes a difference even then. Pretty much anything and everything derived from Exception should give a file and line number - generally that file and line number are the point where the exception was thrown from. Many Errors _can't_ have proper file and line numbers due to how they're thrown, though some of them (such as AssertError) should have proper file and line numbers. So, I don't know why you wouldn't be seeing file and line numbers on Mac OS X. It should be the same as the other OSes. Stack traces are another issue (and I have no idea if Mac OS X currenly has them), but the behavior with regards to file and line numbers in exceptions should be the same for all OSes. I don't know why they wouldn't be. - Jonathan M Davis
Re: opDispatch, duck typing, and error messages
On 2011-04-22 01:54, Jonathan M Davis wrote: Jonathan M Davis wrote: I just checked. Exception _does_ take a default file and line number. Huh, maybe my dmd is getting old. Maybe we should revisit this after the next dmd release. Sounds like one is coming pretty soon with a lot of yummy goodness in it. All of this Exception stuff may be moot. It was in dmd 2.052. I don't know when the change was made though. I might have been the one to change it too. I made several changes a while back to make it so that Exception and Error types had default file and line numbers (and I actually had to remove several on various Errors, because the way that they're actually created makes them not work with default arguments). - Jonathan M Davis It would nice to have file and line info available on Mac OS X as well. -- /Jacob Carlborg
Re: opDispatch, duck typing, and error messages
On 04/22/2011 03:53 AM, Robert Jacques wrote: On Thu, 21 Apr 2011 18:24:55 -0400, Adam D. Ruppe wrote: [snip] Or, there's a whole new approach: e) Duck typing for ranges in to!() might be a bad idea. Again, remember, a class might legitimately offer a range interface, so it would trigger this message without opDispatch. If ranges are meant to be structs, maybe isInputRange should check is(T == struct)? This doesn't sit right with me though. The real problem is to!() - other range functions probably don't overload on classes separately than ranges, so it won't matter there. I think the best thing to do is simply to prefer Object over range. toImpl(T) if (isInputRange!(T) && (!is(T : Object))) Or something along those lines. Why? If the object has it's own toString/writeTo methods, it seems fairly obvious to me anyway that to!string ought to simply call them, regardless or what else there is. There's actually a bug report regarding the toString vs range semantics issue, it's issue 5354 ( http://d.puremagic.com/issues/show_bug.cgi?id=5354 ). Also note that classes (but not structs as of yet, see bug 5719) can provide their own to!T conversions. However, what you ran into deserves a new bug report, since to!string should always be able to fall back to toString and it didn't. Agreed. A programmer who defines toString *means* it to be used for conversion to string (esp. for write* funcs). Please support and vote for this bug ;-) Denis -- _ vita es estrany spir.wikidot.com
Re: opDispatch, duck typing, and error messages
On 04/22/2011 01:25 AM, Adam D. Ruppe wrote:
bearophile wrote:
Maybe exceptions nature should be changed a little so they store
__FILE__ and __LINE__ on default (exceptions without this
information are kept on request, for optimization purposes).
I'd like that. Even with a stack trace, it's nice to have that
available right at the top.
A while ago, someone posted a stack tracer printer for Linux to
the newsgroup. Using that, this program:
void main() {
throw new Exception("test");
}
dmd test60 -debug -g backtrace.d
Prints:
object.Exception: test
./test60(_Dmain+0x30) [0x807a5e8]
./test60(extern (C) int rt.dmain2.main(int, char**) . void runMain()+0x1a)
[0x807d566]
./test60(extern (C) int rt.dmain2.main(int, char**) . void tryExec(void
delegate())+0x24) [0x807d4c0]
./test60(extern (C) int rt.dmain2.main(int, char**) . void runAll()+0x32)
[0x807d5aa]
./test60(extern (C) int rt.dmain2.main(int, char**) . void tryExec(void
delegate())+0x24) [0x807d4c0]
./test60(main+0x96) [0x807d466]
/lib/libc.so.6(__libc_start_main+0xe6) [0xf75a5b86]
./test60() [0x807a4e1]
No line or file info! I'd really like to have something there.
Though, actually, whether it's in the message or in the stack
trace doesn't really matter. As long as it's there somewhere.
Most my custom exceptions use default params in their constructor
to add it. Perhaps the base Exception should too?
Also, addresses could go (useless).
Denis
--
_
vita es estrany
spir.wikidot.com
Re: opDispatch, duck typing, and error messages
On 04/22/2011 12:24 AM, Adam D. Ruppe wrote: I just made an innocent little change to one of my programs, hit compile, and got this vomit: /home/me/d/dmd2/linux/bin/../../src/phobos/std/conv.d(97): Error: template std.conv.toImpl(T,S) if (!implicitlyConverts!(S, T)&& isSomeString!(T)&& isInputRange!(Unqual!(S))&& isSomeChar!(ElementType!(S))) toImpl(T,S) if (!implicitlyConverts!(S ,T)&& isSomeString!(T)&& isInputRange!(Unqual!(S))&& isSomeChar!(ElementType!(S))) matches more than one template declar ation, /home/me/d/dmd2/linux/bin/../../src/phobos/std/conv.d(185):toImpl(T,S) if (isSomeString!(T)&& !isSomeChar!(ElementT ype!(S))&& (isInputRange!(S) || isInputRange!(Unqual!(S and /home/me/d/dmd2/linux/bin/../../src/phobos/std/conv.d(289) :toImpl(T,S) if (is(S : Object)&& isSomeString!(T)) Who... took a bit to figure out what it was saying. The bottom line: one of my classes matched both Object and isInputRange because it offers an unrestricted opDispatch. [...] Things I think would help: [...] Or, there's a whole new approach: e) Duck typing for ranges in to!() might be a bad idea. Again, remember, a class might legitimately offer a range interface, so it would trigger this message without opDispatch. Maybe we could replace template constraints, esp. 'is' stuff, by (structural) interfaces. The difference in my views is structural interface is a compile-time / static feature, while duck typing is runtime/dynamic. If ranges are meant to be structs, maybe isInputRange should check is(T == struct)? This doesn't sit right with me though. The real problem is to!() - other range functions probably don't overload on classes separately than ranges, so it won't matter there. I think the best thing to do is simply to prefer Object over range. toImpl(T) if (isInputRange!(T)&& (!is(T : Object))) Or something along those lines. Why? If the object has it's own toString/writeTo methods, it seems fairly obvious to me anyway that to!string ought to simply call them, regardless or what else there is. Sure. I hit and discussed a similar issue (maybe the same one in fact). The problem was with template formatValue which constraints: (1) for structs, ignore programmer-defined toString in favor of standard format for ranges (2) for classes, simply fail because of conflict (double match) There's a bug report (search for 'formatValue'). Denis -- _ vita es estrany spir.wikidot.com
Re: opDispatch, duck typing, and error messages
On Thu, 21 Apr 2011 18:24:55 -0400, Adam D. Ruppe wrote: [snip] Or, there's a whole new approach: e) Duck typing for ranges in to!() might be a bad idea. Again, remember, a class might legitimately offer a range interface, so it would trigger this message without opDispatch. If ranges are meant to be structs, maybe isInputRange should check is(T == struct)? This doesn't sit right with me though. The real problem is to!() - other range functions probably don't overload on classes separately than ranges, so it won't matter there. I think the best thing to do is simply to prefer Object over range. toImpl(T) if (isInputRange!(T) && (!is(T : Object))) Or something along those lines. Why? If the object has it's own toString/writeTo methods, it seems fairly obvious to me anyway that to!string ought to simply call them, regardless or what else there is. There's actually a bug report regarding the toString vs range semantics issue, it's issue 5354 ( http://d.puremagic.com/issues/show_bug.cgi?id=5354 ). Also note that classes (but not structs as of yet, see bug 5719) can provide their own to!T conversions. However, what you ran into deserves a new bug report, since to!string should always be able to fall back to toString and it didn't.
Re: opDispatch, duck typing, and error messages
Jonathan M Davis wrote: > It was in dmd 2.052. This is almost definitely my error then... I still have 2.050! I didn't realize so much has passed since my last update :S
Re: opDispatch, duck typing, and error messages
On 4/22/11, Sean Kelly wrote: > On Apr 21, 2011, at 4:10 PM, Andrej Mitrovic wrote: > >> Btw, there is a stack trace for Windows and D2, see here: >> http://3d.benjamin-thaut.de/?p=15 > > Already in the next DMD release. > Whoa, the next release is gonna be big.
Re: opDispatch, duck typing, and error messages
> Jonathan M Davis wrote: > > I just checked. Exception _does_ take a default file and line number. > > Huh, maybe my dmd is getting old. > > Maybe we should revisit this after the next dmd release. Sounds like > one is coming pretty soon with a lot of yummy goodness in it. All > of this Exception stuff may be moot. It was in dmd 2.052. I don't know when the change was made though. I might have been the one to change it too. I made several changes a while back to make it so that Exception and Error types had default file and line numbers (and I actually had to remove several on various Errors, because the way that they're actually created makes them not work with default arguments). - Jonathan M Davis
Re: opDispatch, duck typing, and error messages
> Jonathan M Davis wrote:
> > It _does_ generally make sense for the file and line number to be
> > from the throw point rather than the point where you called the
> > function (especially when the throw point could be several function
> > calls away in the stack), but without a proper stack trace, you
> > have no way of knowing where in your code the problem is.
>
> I believe I agree completely.
>
> > Now, in the case of something like to, the types are known at
> > compile time, so in many cases, it should be able to give a
> > compile time error via a template constraint, but it's not able
> > to do that in all cases.
>
> Indeed. And it usually does. The problem is that the error can be
> pretty hard to read.
>
> Here's one simple case:
>
> ===
>
> import std.conv;
>
> struct Test {}
>
> void main() {
> Test t;
> int a = to!int(t);
> }
>
> ===
>
> /home/me/d/dmd2/linux/bin/../../src/phobos/std/conv.d(95): Error: template
> std.conv.toImpl(T,S) if (!implicitlyConverts!(S,T) && isSomeString!(T) &&
> isInputRange!(Unqual!(S)) && isSomeChar!(ElementType!(S))) does not match
> any function template declaration
> /home/me/d/dmd2/linux/bin/../../src/phobos/std/conv.d(95): Error: template
> std.conv.toImpl(T,S) if (!implicitlyConverts!(S,T) && isSomeString!(T) &&
> isInputRange!(Unqual!(S)) && isSomeChar!(ElementType!(S))) cannot deduce
> template function from argument types !(int)(Test)
> /home/me/d/dmd2/linux/bin/../../src/phobos/std/conv.d(95): Error: template
> instance errors instantiating template
> /home/me/d/dmd2/linux/bin/../../src/phobos/std/conv.d(7): Error: template
> instance std.conv.to!(int).to!(Test) error instantiating
>
>
> Holy crap!
>
> But, if you know the secret there - to look at the last line -
> it does tell you enough to do some useful stuff. Alas, it doesn't
> tell where in *your* code the problem is, but it does tell the
> types you asked for, so it's pretty useful.
>
> Still, I'd like it if that was formatted nicer, and it went the
> final step of telling me where in my code the problem is too.
>
>
> Then, you have the problem if your type matches two templates.
> Then you have the vomit in my opening post, where it doesn't even
> tell you what types it's having trouble with!
Template errors tend to be fairly good (especially if you're used to reading
them) when you're only dealing with one template, but as soon as the template
is overloaded, you're screwed. It generally just gives the first template and
says that you didn't match it, and often the template that you're actually
trying to use is quite different. But short of giving _all_ of the possible
template declarations that it failed, I'm not quite sure what we could do to
fix that.
- Jonathan M Davis
Re: opDispatch, duck typing, and error messages
Jonathan M Davis wrote: > I just checked. Exception _does_ take a default file and line number. Huh, maybe my dmd is getting old. Maybe we should revisit this after the next dmd release. Sounds like one is coming pretty soon with a lot of yummy goodness in it. All of this Exception stuff may be moot.
Re: opDispatch, duck typing, and error messages
Jonathan M Davis wrote:
> It _does_ generally make sense for the file and line number to be
> from the throw point rather than the point where you called the
> function (especially when the throw point could be several function
> calls away in the stack), but without a proper stack trace, you
> have no way of knowing where in your code the problem is.
I believe I agree completely.
> Now, in the case of something like to, the types are known at
> compile time, so in many cases, it should be able to give a
> compile time error via a template constraint, but it's not able
> to do that in all cases.
Indeed. And it usually does. The problem is that the error can be
pretty hard to read.
Here's one simple case:
===
import std.conv;
struct Test {}
void main() {
Test t;
int a = to!int(t);
}
===
/home/me/d/dmd2/linux/bin/../../src/phobos/std/conv.d(95): Error: template
std.conv.toImpl(T,S) if (!implicitlyConverts!(S,T) && isSomeString!(T) &&
isInputRange!(Unqual!(S)) && isSomeChar!(ElementType!(S))) does not match any
function template declaration
/home/me/d/dmd2/linux/bin/../../src/phobos/std/conv.d(95): Error: template
std.conv.toImpl(T,S) if (!implicitlyConverts!(S,T) && isSomeString!(T) &&
isInputRange!(Unqual!(S)) && isSomeChar!(ElementType!(S))) cannot deduce
template
function from argument types !(int)(Test)
/home/me/d/dmd2/linux/bin/../../src/phobos/std/conv.d(95): Error: template
instance errors instantiating template
/home/me/d/dmd2/linux/bin/../../src/phobos/std/conv.d(7): Error: template
instance
std.conv.to!(int).to!(Test) error instantiating
Holy crap!
But, if you know the secret there - to look at the last line -
it does tell you enough to do some useful stuff. Alas, it doesn't
tell where in *your* code the problem is, but it does tell the
types you asked for, so it's pretty useful.
Still, I'd like it if that was formatted nicer, and it went the
final step of telling me where in my code the problem is too.
Then, you have the problem if your type matches two templates.
Then you have the vomit in my opening post, where it doesn't even
tell you what types it's having trouble with!
> One example of that is converting a string to anything else. The
> value of the string determines whether the conversion is valid
> rather than the types being enough at compile time.
The runtime error is actually pretty good. If it had a nice
stack trace with line numbers I'd call it outright excellent.
So I agree with your conclusion too about the stack trace!
BTW, while I'm talking about this, is RangeError at all possible
to include the actual key that was out of range?
int[] b;
int c = b[3];
core.exception.RangeError@test60(7): Range violation
Good, but I'd call it great if it could say Range violation (3) or
something like that.
I imagine since it's an Error there might be memory allocation
restrictions... but if it's possible, that'd be way cool too.
Re: opDispatch, duck typing, and error messages
On Apr 21, 2011, at 4:10 PM, Andrej Mitrovic wrote: > Btw, there is a stack trace for Windows and D2, see here: > http://3d.benjamin-thaut.de/?p=15 Already in the next DMD release.
Re: opDispatch, duck typing, and error messages
> bearophile wrote:
> > Maybe exceptions nature should be changed a little so they store
> >
> > __FILE__ and __LINE__ on default (exceptions without this
> > information are kept on request, for optimization purposes).
>
> I'd like that. Even with a stack trace, it's nice to have that
> available right at the top.
>
> A while ago, someone posted a stack tracer printer for Linux to
> the newsgroup. Using that, this program:
>
> void main() {
> throw new Exception("test");
> }
>
> dmd test60 -debug -g backtrace.d
>
> Prints:
>
> object.Exception: test
>
> ./test60(_Dmain+0x30) [0x807a5e8]
> ./test60(extern (C) int rt.dmain2.main(int, char**) . void runMain()+0x1a)
> [0x807d566] ./test60(extern (C) int rt.dmain2.main(int, char**) . void
> tryExec(void delegate())+0x24) [0x807d4c0]
> ./test60(extern (C) int rt.dmain2.main(int, char**) . void runAll()+0x32)
> [0x807d5aa] ./test60(extern (C) int rt.dmain2.main(int, char**) . void
> tryExec(void delegate())+0x24) [0x807d4c0]
> ./test60(main+0x96) [0x807d466]
> /lib/libc.so.6(__libc_start_main+0xe6) [0xf75a5b86]
> ./test60() [0x807a4e1]
>
>
>
> No line or file info! I'd really like to have something there.
> Though, actually, whether it's in the message or in the stack
> trace doesn't really matter. As long as it's there somewhere.
>
> Most my custom exceptions use default params in their constructor
> to add it. Perhaps the base Exception should too?
I just checked. Exception _does_ take a default file and line number. So,
anything derived from Exception doesn't have a file and line number, something
is amiss.
- Jonathan M Davis
Re: opDispatch, duck typing, and error messages
bearophile wrote:
> Maybe exceptions nature should be changed a little so they store
> __FILE__ and __LINE__ on default (exceptions without this
> information are kept on request, for optimization purposes).
I'd like that. Even with a stack trace, it's nice to have that
available right at the top.
A while ago, someone posted a stack tracer printer for Linux to
the newsgroup. Using that, this program:
void main() {
throw new Exception("test");
}
dmd test60 -debug -g backtrace.d
Prints:
object.Exception: test
./test60(_Dmain+0x30) [0x807a5e8]
./test60(extern (C) int rt.dmain2.main(int, char**) . void runMain()+0x1a)
[0x807d566]
./test60(extern (C) int rt.dmain2.main(int, char**) . void tryExec(void
delegate())+0x24) [0x807d4c0]
./test60(extern (C) int rt.dmain2.main(int, char**) . void runAll()+0x32)
[0x807d5aa]
./test60(extern (C) int rt.dmain2.main(int, char**) . void tryExec(void
delegate())+0x24) [0x807d4c0]
./test60(main+0x96) [0x807d466]
/lib/libc.so.6(__libc_start_main+0xe6) [0xf75a5b86]
./test60() [0x807a4e1]
No line or file info! I'd really like to have something there.
Though, actually, whether it's in the message or in the stack
trace doesn't really matter. As long as it's there somewhere.
Most my custom exceptions use default params in their constructor
to add it. Perhaps the base Exception should too?
Re: opDispatch, duck typing, and error messages
Btw, there is a stack trace for Windows and D2, see here: http://3d.benjamin-thaut.de/?p=15
Re: opDispatch, duck typing, and error messages
> This is a more general problem of runtime errors, not just of to!(). Maybe > exceptions nature should be changed a little so they store __FILE__ and > __LINE__ on default (exceptions without this information are kept on > request, for optimization purposes). Vote up for that. At least it should do that in -debug mode. It's completely useless getting an error message with a file and line number for an internal Phobos function, like some funcImpl() private function, when the fault is a runtime argument.
Re: opDispatch, duck typing, and error messages
> Adam D. Ruppe: > > c) Maybe Phobos could help out somehow? Another thing to!() > > annoys the living crap of me with is it's runtime errors. It, again, > > doesn't tell me where in my code the problem occurred. > > > > Perhaps have it take default __FILE__ and __LINE__ args to print out > > too? I think this can help both compile and runtime errors. > > This is a more general problem of runtime errors, not just of to!(). Maybe > exceptions nature should be changed a little so they store __FILE__ and > __LINE__ on default (exceptions without this information are kept on > request, for optimization purposes). Most exceptions end up with file and line numbers. The problem is generally not that they don't have a file or line number, it's that the file and line number is from inside of a function that you called instead of your own code. As long as you have a stack trace, it's not all that big a problem, but if you're on Windows, then there are no stack traces yet and you're screwed. It _does_ generally make sense for the file and line number to be from the throw point rather than the point where you called the function (especially when the throw point could be several function calls away in the stack), but without a proper stack trace, you have no way of knowing where in your code the problem is. Now, in the case of something like to, the types are known at compile time, so in many cases, it should be able to give a compile time error via a template constraint, but it's not able to do that in all cases. One example of that is converting a string to anything else. The value of the string determines whether the conversion is valid rather than the types being enough at compile time. So, in some cases, you _have_ to have an exception at runtime rather than a compile time error. Whether to does as good a job with making errors compile time errors as much as it can, I don't know, but on some level, we're stuck. But generally, I think that the real problem is the lack of a stack trace. You generally get them on Linux but not Windows. Most exceptions _should_ be grabbing the file and line number that they're thrown from. I don't recall of Exception can or not (Error _can't_ due to some low level stuff), but pretty much everything derived from Exception certainly can and should. - Jonathan M Davis
Re: opDispatch, duck typing, and error messages
Adam D. Ruppe: > c) Maybe Phobos could help out somehow? Another thing to!() > annoys the living crap of me with is it's runtime errors. It, again, > doesn't tell me where in my code the problem occurred. > > Perhaps have it take default __FILE__ and __LINE__ args to print out > too? I think this can help both compile and runtime errors. This is a more general problem of runtime errors, not just of to!(). Maybe exceptions nature should be changed a little so they store __FILE__ and __LINE__ on default (exceptions without this information are kept on request, for optimization purposes). Bye, bearophile
opDispatch, duck typing, and error messages
I just made an innocent little change to one of my programs, hit
compile, and got this vomit:
/home/me/d/dmd2/linux/bin/../../src/phobos/std/conv.d(97): Error: template
std.conv.toImpl(T,S) if (!implicitlyConverts!(S,
T) && isSomeString!(T) && isInputRange!(Unqual!(S)) &&
isSomeChar!(ElementType!(S))) toImpl(T,S) if (!implicitlyConverts!(S
,T) && isSomeString!(T) && isInputRange!(Unqual!(S)) &&
isSomeChar!(ElementType!(S))) matches more than one template declar
ation, /home/me/d/dmd2/linux/bin/../../src/phobos/std/conv.d(185):toImpl(T,S)
if (isSomeString!(T) && !isSomeChar!(ElementT
ype!(S)) && (isInputRange!(S) || isInputRange!(Unqual!(S and
/home/me/d/dmd2/linux/bin/../../src/phobos/std/conv.d(289)
:toImpl(T,S) if (is(S : Object) && isSomeString!(T))
Who... took a bit to figure out what it was saying. The bottom
line: one of my classes matched both Object and isInputRange because
it offers an unrestricted opDispatch.
The fix:
// note the constraint
string opDispatch(string name)() if(name != "popFront") {}
(I'm sure empty or front would have worked just as well, but popFront
I'm sure I didn't actually use anywhere for this.)
This post is to serve as two things: an FYI in case you see something
like this yourself, and to have a discussion on what we can do to
improve the situation.
A constraint like this wouldn't work of the Object was actually
supposed to be a range.
So, what can we do to improve that message? As it is now, it's
close to useless. Yeah, I was able to track down what it meant, but
only after I hacked up my copy of Phobos to tell me what T and S
actually were in the instantiation of to... then, it was obvious what
the error meant, but before, well, I pity the poor newbie who
stumbles upon that!
Things I think would help:
a) If the compiler gave some kind of stack trace in this instance. An
error message pointing solely at std.conv doesn't help much. In a
lot of template error messages, the kind of trace I want
already exists, so I suspect 90% of the work to implement it is
already done.
b) Format those constraints a little. Just put a "\n\t" before the
if and a "\n" before the function name. I think some whitespace
would help a lot in readability. Sure, newbs might still not get it,
but at least it won't be a blob of wtf.
Alas, I've looked at the compiler, but aren't to the point where I
can contribute code to it myself. Well, maybe I could do the
formatting change, but I haven't tried yet.
Regardless, let's look at other options.
c) Maybe Phobos could help out somehow? Another thing to!()
annoys the living crap of me with is it's runtime errors. It, again,
doesn't tell me where in my code the problem occurred.
Perhaps have it take default __FILE__ and __LINE__ args to print out
too? I think this can help both compile and runtime errors.
d) Also in Phobos, I wonder if we can beautify the message somehow.
I don't have any idea how to do this in a scalable way.
It could static if (matches constraint 1 and constraint 2)
static assert("pretty message"), but there's no chance that would
scale well.
So I don't know here.
Or, there's a whole new approach:
e) Duck typing for ranges in to!() might be a bad idea. Again, remember,
a class might legitimately offer a range interface, so it would
trigger this message without opDispatch.
If ranges are meant to be structs, maybe isInputRange should check
is(T == struct)? This doesn't sit right with me though. The real
problem is to!() - other range functions probably don't overload
on classes separately than ranges, so it won't matter there.
I think the best thing to do is simply to prefer Object over range.
toImpl(T) if (isInputRange!(T) && (!is(T : Object)))
Or something along those lines. Why? If the object has it's own
toString/writeTo methods, it seems fairly obvious to me anyway that
to!string ought to simply call them, regardless or what else there is.
I kinda blabbered here, but in the end, I think my previous paragraph
is the big thing. It's a fairly minor Phobos change. Any objections
to it?
Note btw that I'd still like the error messages to be prettier, but
I'm ok doing it one step at a time.
Re: duck!
On 11/11/2010 15:22, Andrei Alexandrescu wrote:
On 11/11/10 6:30 AM, Bruno Medeiros wrote:
On 17/10/2010 20:11, Andrei Alexandrescu wrote:
On 10/17/2010 01:09 PM, Jeff Nowakowski wrote:
On 10/16/2010 04:05 PM, Andrei Alexandrescu wrote:
It's a subset of duck typing. I don't think calling a function that
supports a limited form of duck typing "duck" is a lie.
I'm sure if it was on a Go slide you would.
Probably not in as strong terms, but if you want to point out that I'm
biased... what can I do? I'm a simple man.
Andrei
When I first heard you say you were biased (in the Google Talk), I
thought you were being facetious, or just exaggerating.
I'm not so sure anymore, and I hope that is not the case. Because, as
I'm sure you must realize, being biased for D will only result in an
outcome of mild to severe annoyance and loss of credibility from:
* people biased for languages which are perceived to be competitors to D
(like Go).
* people who are (or strive to be) unbiased.
And given who you are (one of the designers of D), this outcome will
apply not just to yourself, but D as well, which obviously is not a good
thing.
I think I ascribe a milder meaning than you to "bias". It's in human
nature to have preferences, and it's self-evident that I'm biased in
favor of various facets of D's approach to computing. A completely
unbiased person would have a hard time working on anything creative.
Andrei
I don't think the bias above is just a case of preferences of one thing
over the other. Having preferences is perfectly fine, as in "I prefer
this approach", or even "I think this approach is more effective than
that one".
Another thing is to describe reality in inaccurate terms ("I think
approach A has property Z", when it doesn't), and/or to have a double
standard when describing or analyzing something else.
--
Bruno Medeiros - Software Engineer
Re: duck!
On Thu, Nov 11, 2010 at 11:25 AM, Andrew Wiley wrote: > On Thu, Nov 11, 2010 at 10:01 AM, Bruno Medeiros > wrote: > >> On 11/11/2010 14:19, Bruno Medeiros wrote: >> >>> way in the future. I think dynamic languages are somewhat of a niche >>> (even if a growing one), but not really heading to be mainstream in >>> medium/large scale projects. >>> >> >> Sorry, I actually meant "I think dynamic _typing_ is somewhat of a niche" >> rather than the above. Yes, the two are closely related, but they are not >> the same. >> For example, I wouldn't be surprised if in the future certain >> dynamically-typed languages gain some static-typing capabilities. (like the >> inverse is happening) >> >> > From reading about this, it seems like what D has is very similar to what > Scala calls "Structural Typing" (see > http://codemonkeyism.com/scala-goodness-structural-typing/). The > difference is that Scala tends to use structural typing with inline type > declarations (although they don't have to be inline). However, the basic > concept is the same, where a class is dynamically checked for compliance > with a static type. Not quite dynamic typing, but definitely related. > If you're after a more accurate description, how would that work? > > Andrew Wiley > Actually, that's wrong, as the class is statically checked for compliance with a static type, but still.
Re: duck!
On Thu, Nov 11, 2010 at 10:01 AM, Bruno Medeiros wrote: > On 11/11/2010 14:19, Bruno Medeiros wrote: > >> way in the future. I think dynamic languages are somewhat of a niche >> (even if a growing one), but not really heading to be mainstream in >> medium/large scale projects. >> > > Sorry, I actually meant "I think dynamic _typing_ is somewhat of a niche" > rather than the above. Yes, the two are closely related, but they are not > the same. > For example, I wouldn't be surprised if in the future certain > dynamically-typed languages gain some static-typing capabilities. (like the > inverse is happening) > > >From reading about this, it seems like what D has is very similar to what Scala calls "Structural Typing" (see http://codemonkeyism.com/scala-goodness-structural-typing/). The difference is that Scala tends to use structural typing with inline type declarations (although they don't have to be inline). However, the basic concept is the same, where a class is dynamically checked for compliance with a static type. Not quite dynamic typing, but definitely related. If you're after a more accurate description, how would that work? Andrew Wiley
Re: duck!
On 11/11/2010 14:19, Bruno Medeiros wrote: way in the future. I think dynamic languages are somewhat of a niche (even if a growing one), but not really heading to be mainstream in medium/large scale projects. Sorry, I actually meant "I think dynamic _typing_ is somewhat of a niche" rather than the above. Yes, the two are closely related, but they are not the same. For example, I wouldn't be surprised if in the future certain dynamically-typed languages gain some static-typing capabilities. (like the inverse is happening) -- Bruno Medeiros - Software Engineer
Re: duck!
On 11/11/10 6:30 AM, Bruno Medeiros wrote: On 17/10/2010 20:11, Andrei Alexandrescu wrote: On 10/17/2010 01:09 PM, Jeff Nowakowski wrote: On 10/16/2010 04:05 PM, Andrei Alexandrescu wrote: It's a subset of duck typing. I don't think calling a function that supports a limited form of duck typing "duck" is a lie. I'm sure if it was on a Go slide you would. Probably not in as strong terms, but if you want to point out that I'm biased... what can I do? I'm a simple man. Andrei When I first heard you say you were biased (in the Google Talk), I thought you were being facetious, or just exaggerating. I'm not so sure anymore, and I hope that is not the case. Because, as I'm sure you must realize, being biased for D will only result in an outcome of mild to severe annoyance and loss of credibility from: * people biased for languages which are perceived to be competitors to D (like Go). * people who are (or strive to be) unbiased. And given who you are (one of the designers of D), this outcome will apply not just to yourself, but D as well, which obviously is not a good thing. I think I ascribe a milder meaning than you to "bias". It's in human nature to have preferences, and it's self-evident that I'm biased in favor of various facets of D's approach to computing. A completely unbiased person would have a hard time working on anything creative. Andrei
Re: duck!
On 17/10/2010 20:11, Andrei Alexandrescu wrote: On 10/17/2010 01:09 PM, Jeff Nowakowski wrote: On 10/16/2010 04:05 PM, Andrei Alexandrescu wrote: It's a subset of duck typing. I don't think calling a function that supports a limited form of duck typing "duck" is a lie. I'm sure if it was on a Go slide you would. Probably not in as strong terms, but if you want to point out that I'm biased... what can I do? I'm a simple man. Andrei When I first heard you say you were biased (in the Google Talk), I thought you were being facetious, or just exaggerating. I'm not so sure anymore, and I hope that is not the case. Because, as I'm sure you must realize, being biased for D will only result in an outcome of mild to severe annoyance and loss of credibility from: * people biased for languages which are perceived to be competitors to D (like Go). * people who are (or strive to be) unbiased. And given who you are (one of the designers of D), this outcome will apply not just to yourself, but D as well, which obviously is not a good thing. -- Bruno Medeiros - Software Engineer
Re: duck!
On 16/10/2010 19:16, Walter Bright wrote: Being the upstart language, D needs now and then something a little more attention-getting than generic terms. The "duck" feature is important for two reasons: 1. duck typing is all the rage now What??... :o I think this is very much a wrong perception! Sure, there has been a lot of articles, publicity and buzz surrounding duck typing in the past few years, but that doesn't meant it's "all the rage". More concretely, it doesn't mean that duck typing is popular, either now, or heading that way in the future. I think dynamic languages are somewhat of a niche (even if a growing one), but not really heading to be mainstream in medium/large scale projects. Rather I think that the duck typing fanboys are just very vocal about it. (Kinda like the Tea Party movement... ) BTW, just as a clarifying side note, duck typing is nothing new in terms of language features. Duck typing is just dynamic typing as combined with Object Oriented. What is new about duck typing is not so much in the language, but rather the development philosophy that states: * dynamic typing with OO is an equally valid approach (if not better) than traditional static typing OO, for thinking about objects and their behavior, * documentation, clear code, and testing are good enough to ensure correct usage (especially testing, in some circles). Note: I'm not implying I agree with the above, I'm just paraphrasing. -- Bruno Medeiros - Software Engineer
Re: duck!
On 16/10/2010 21:30, Michel Fortin wrote:
On 2010-10-16 16:05:52 -0400, Andrei Alexandrescu
said:
On 10/16/2010 02:54 PM, kenji hara wrote:
Adapter-Pattern! I'd have forgotten the name.
It is NOT equals to duck-typing.
It's a subset of duck typing. I don't think calling a function that
supports a limited form of duck typing "duck" is a lie.
Not a lie, just a word with a deceptive meaning that'll lead people to
believe something else than the truth. Some cynically call that
marketing speech.
I have to agree with Kenji and Michael here: this is not duck typing.
Duck typing is like example "6. Dynamic object type& dynamic signature"
in Kenji's last post.
The problem is not just strictly the name of the adapter function, but
that from this whole thread there was that the implication that you
Andrei, and Walter, were willing to market D as "having duck typing", or
"supporting duck typing", without any qualification on that support
("subset of", "limited form of", or even just "form of" like the Go
slides). So I agree with Michael, this would be inaccurate at best, and
deceitful at worst.
We could argue nomenclature, but there is a much more simple litmus
test: any non-D developer who used proper duck typing before, and then
heard "D has duck typing" from some official sources, and then tried D
out and found out how the actual feature worked, would almost certainly
feel deceived or disappointed.
--
Bruno Medeiros - Software Engineer
Re: Duck typing for structs
On 10/21/2010 12:58 PM, bearophile wrote: Just a question. Aren't lines like: if (is(typeof(candidate) == const)) Better as static ifs? Bye, bearophile Probably they are; this was my first try at compile-time functions, and while writing it I kept crossing the line between what could and could not be evaluated at compile-time/as a condition to a static if, so I made most of the "ifs" non-static until I got it working. -- Ash
Re: Duck typing for structs
Ash Logan: > but I wanted to see what the D community thought of it. Just a question. Aren't lines like: if (is(typeof(candidate) == const)) Better as static ifs? Bye, bearophile
Duck typing for structs
Hello all, I was experimenting with Kenji Hara's interfaces.d, and I thought it would be interesting to be able to adapt not just objects but struct values to an interface. So I came up with a hacky solution, adapter.d, and put it on Google Docs at http://goo.gl/Y7Oa in case anyone is interested. The unit tests have examples of usage with structs and classes (including classes with methods added by mixin templates, and structs with aliases to methods); there are several weird bugs relating to overloaded methods, but more things work than I expected to when I started. I don't know if this could turn into something useful, or if it's just a curiosity, but I wanted to see what the D community thought of it. -- Ash
Re: duck!
On 10/19/2010 7:01 PM, Andrei Alexandrescu wrote: > On 10/19/10 17:50 CDT, Roman Ivanov wrote: >> Hm, how about this? >> >> auto d = make!Drawable(obj); >> >> Reads "make Drawable from obj". > > "make" has factory conotations. I think it's best to concede and call > the artifact "adapt". > > Andrei It's true about factory connotations. I think "adapt" would work pretty well as a name. ... A good way of looking at API naming might be by recalling APIs for other languages/libraries and trying to avoid the bad things they had.
Re: duck!
Andrei Alexandrescu wrote: I think it's best to concede and call the artifact "adapt". Aww. I liked duck. -- Simen
Re: duck!
On 10/19/10 17:50 CDT, Roman Ivanov wrote: On 10/16/2010 1:19 PM, Andrei Alexandrescu wrote: The problem with "adaptTo" is that, just like itoa or printf, it is too boring to have marketing value. I think the feature is going to be _big_. We can't leave a big feature to a name like "adaptTo". The New York Times won't have a headline like "adaptTo changes the name of the game". IMO, you overestimate marketing value of function names. The paramount concern with API naming should be clarity. Reading and understanding code should be easy. Ideally, discussing code and searching for examples online should be easy too. Personally, I like when features are demonstrated by examples. The clearer the example, the easier it is to convince me that the language/API/code does something good. This is also part of my beef with "as" or "to" for the feature. "As" is difficult to talk about. "Oh my God, D has 'as'!" "Has ass?" My problem with "as" would be different. When something has a two-letter name (is, in, as, to, and so on) I tend to assume it's a language keyword, unless I know the language enough to say it's not. C# uses "as" for casting, for example. I'd go with the longer "ducktype". Length is not as important as evocative power and brand name! auto d = ducktype!Drawable(obj); 99.99% of programmers will have an idea of what's going on. ducktype is a bit better than duck. Hm, how about this? auto d = make!Drawable(obj); Reads "make Drawable from obj". "make" has factory conotations. I think it's best to concede and call the artifact "adapt". Andrei
Re: duck!
On 10/16/2010 1:19 PM, Andrei Alexandrescu wrote: > The problem with "adaptTo" is that, just like itoa or printf, it is too > boring to have marketing value. I think the feature is going to be > _big_. We can't leave a big feature to a name like "adaptTo". The New > York Times won't have a headline like "adaptTo changes the name of the > game". IMO, you overestimate marketing value of function names. The paramount concern with API naming should be clarity. Reading and understanding code should be easy. Ideally, discussing code and searching for examples online should be easy too. Personally, I like when features are demonstrated by examples. The clearer the example, the easier it is to convince me that the language/API/code does something good. > This is also part of my beef with "as" or "to" for the feature. "As" is > difficult to talk about. "Oh my God, D has 'as'!" "Has ass?" My problem with "as" would be different. When something has a two-letter name (is, in, as, to, and so on) I tend to assume it's a language keyword, unless I know the language enough to say it's not. C# uses "as" for casting, for example. > I'd go with the longer "ducktype". Length is not as important as > evocative power and brand name! > > auto d = ducktype!Drawable(obj); > > 99.99% of programmers will have an idea of what's going on. ducktype is a bit better than duck. Hm, how about this? auto d = make!Drawable(obj); Reads "make Drawable from obj".
Re: duck!
On Sat, 16 Oct 2010 18:20:37 -0400, Walter Bright wrote: Steven Schveighoffer wrote: I'm just saying that marketability of D does not change no matter what appropriate term you choose. And this is our fundamental disagreement. I think the choices of names matters a lot. If names don't matter, why not name your son "Sue" ? :-) Notice I said *appropriate* term :) And he prefers Susan. But were there functions named zoomTechnology() and smartLink()? Were their tools named zoom or smartl or something? Is that what pushed them over the edge, or was it the bullet on the packaging that said: * Includes zoom technology! I don't believe that there is any fundamental difference between the name of a function and the name of the technology. The name of the technology can be inventive, super-descriptive, slightly exaggerated, a marketing term. The name of a function can be that, but doesn't have to be. Preferrably it should be succinct and related to the technology. 'duck' is a fine term, but as a function name is not going to score any marketing points. But people don't search google for "duck typing programming languages" and pick the language they're going to use from this list! They may very well search "duck typing in the D programming language". Heck, that's what I do when I'm investigating whether language X supports feature Y. I do it a lot. Most people will look at something like http://en.wikipedia.org/wiki/Duck_typing and find D precariously missing because as Michel Fortin pointed out, adaptTo is not duck typing. I think you are really going cuckoo over this feature like it's the best thing since ranges, and I don't see it being that. I am happy with the name ranges for what it does, I think it's exactly right. Am I going cuckoo over this one? Perhaps. But I also believe that even getting the small details right is important. As do I. To suggest that not liking the term 'duck' the best means a lack of attention to detail is a little argumentative, don't you think? It reminds me of when a friend visited my house. After a very brief interval, he announced could tell it was a quality house, not a cheap facade. Intrigued, I asked him how. He said that the screw slots holding the wall plates on were all aligned the same way. It's a wholly irrelevant detail, added absolutely nothing to the function, but he said such attention to detail indicated the contractor cared about getting the details right. Really? That's like saying a car is very well maintained because the headlights are properly aligned. I'd highly advise against using the "screw alignment test" for buying a house ;) Invariant vs. immutable is not the same as adaptTo vs. duck. Invariant already had a meaning in D1, and when choosing a new name, it was logical to use immutable. Is immutable an 'exciting marketing term'? No, it's as boring as they come. But it's definitely the best term for the job. Let's focus on choosing the best term for what 'adaptTo' does, and when we market that D does duck typing in an article or a list of features (that shows up on google), we can include all the features of D that do duck typing. With invariant I *always* had to explain it (even to people with no knowledge of the D1 meaning), and people would looked puzzled even after the explanation. With immutable, I stopped having to explain it. The name change was a big win. Yes, because using invariant to mean immutable is somewhat of a misnomer. The CS meaning of invariant is: http://en.wikipedia.org/wiki/Invariant_%28computer_science%29. I think you'd agree that as!X and adaptTo!X are not obscure terms that don't describe the function properly. Heck, the pattern being implemented here is the adapter pattern, so adaptTo seems like a pretty correct term. -Steve
Re: duck!
On Sat, 16 Oct 2010 17:50:53 -0400, Andrei Alexandrescu wrote: On 10/16/2010 04:00 PM, Steven Schveighoffer wrote: But naming the function that does duck typing 'duck' doesn't seem to me like it makes or breaks D at all. You do find it important, otherwise you wouldn't have spent cumulative hours arguing about it. Honestly, I am not objecting to the name duck! It's a fine name, and successfully describes the meaning (as long as you explain it to newbies who have no idea what 'duck typing' is). The only issue I have is the statement that naming the function duck is somehow a marketing benefit, or that naming it something that correctly describes the function, but isn't duck, will somehow push away users. -Steve
Re: duck!
On Sat, 16 Oct 2010 18:04:23 -0400, Walter Bright wrote: Steven Schveighoffer wrote: On Sat, 16 Oct 2010 16:31:34 -0400, Walter Bright wrote: If I google for "adapt for D" I'll get a hopeless mess of irrelevant links. "duck typing for D" should be much better. Remember that google ranks pages by relevance, and searching for "duck" will give higher ranking for pages with "duck" in the url, title, headings, etc. That's just what we want. And it should come up with the page on digitalmars.com titled 'duck typing in D' which describes how to use templates or the adaptTo type to achieve duck typing. When writing fiction, it's a good idea to constantly shift which words used to describe something. But when writing tech manuals, and when making things search engine friendly, it pays to use a single term and use it consistently. For example, once upon a time I read some article on arrays, and it variously referred to the array "elements", "entries", and "values". Really, that sucked, as the reader was left being not quite sure if they meant the same thing or not. If you expect people to search for "duck typing" (and I do) then why stick another level of indirection? Call it a "duck". When you find yourself constantly saying "duck typing: see adaptTo", then you named it wrong. Is this a case of foresight is 20/20? Look, you can't predict the future, and knowing what you will constantly be saying isn't possible. You could constantly be saying 'yeah, I know duck isn't the only way to do duck typing in D, but we felt it was a good descriptive name.' And not having to constantly say anything isn't proof that you have preemptively avoided it. But it doesn't matter anyways. My point is, marketing has nothing to do with naming functions. People will not decide to use or not use a language based on a function name. If the name describes the function properly, then it will not be noticed as a defect, and few will have problems with it. All three suggestions (adaptTo, as, and duck) satisfy this IMO, so really this argument has nothing to do with the name. It's all about the incorrect belief that the name itself will somehow be seen as a marketing benefit. You're making a lake out of a duck pond ;) -Steve
Re: duck!
It would be ironic to call it go instead of duck.
- it helps memorizing what it does
- it's a funny reminder of the Go vs Go! naming issue with D template
instanciation (!)
- "we can do that, with templates"
> auto d = go!Drawable(c); // awes
Andrei Alexandrescu Wrote:
> I was talking to Walter about Kenji's adaptTo. We both think it's a very
> powerful enabler, but adaptTo is a bland name. After discussing a few
> marketing strategies, I proposed "duck". It's short, simple, and evokes
> "duck typing".
>
> class C
> {
> int draw(){ return 10; }
> }
> interface Drawable
> {
> long draw();
> }
> ...
> auto c = new C;
> auto d = duck!Drawable(c); // awes
>
> Kenji, I'll be looking forward to your submission :o). Would be great to
> allow structs to duck, too!
>
>
> Andrei
Re: duck!
If you got opera "g define:bikeshedding", else google "define:bikeshedding" On Sun, 17 Oct 2010 10:13:54 +0300, Jonathan M Davis wrote: On Saturday 16 October 2010 23:13:52 abram wrote: Walter Bright wrote: > Andrei Alexandrescu wrote: >> Please substitute: "X does duck typing in the D programming >> language". What is X? >> >> FWIW this was the story with "immutable". Walter got tired of >> explaining: "Invariant implements immutable types in the D >> programming language". > > Boy did I ever get tired of that. It's a classic example of names > mattering - it's not just a bikeshed color. Maybe you should explain "bikeshed". Did someone steal your bike? From your parent's shed? http://en.wiktionary.org/wiki/bikeshedding -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: duck!
I was busy, so just two comments about this long thread. Walter Bright: > A lot of people do think duck typing is very important. But it's better to add features to D because they are useful for D programs, and not because lot of people want "duck typing" in general. C#4 has added the "dynamic" keyword, its not named WizBang!, and its semantics is powerful and very well integrated with the rest of the language and virtual machine. This is how C# is better than D both in nomenclature style and in substance: http://msdn.microsoft.com/en-us/library/dd264736.aspx If you want you may use Google to find other better pages about the "dynamic" of C#4. --- Andrej Mitrovic > What's all this arguing about anyway? > > import std.conv : duck; > > alias duck as; > alias duck adaptTo; > > Done deal. That's false/misleading. I've once renamed "writeln" as "putr" in one of my code snippets and Walter answered me he didn't know what "putr" means despite the first line in the 10-lines long program was the import std.stdio: putr = writeln; "alias" is useful, but it's also misleading. Usually if you want your code to be easy to understand you have to stick with the default names that everyone else uses. Something partially related, about abuse of typedef in Linux kernel: http://lkml.indiana.edu/hypermail/linux/kernel/0206.1/0402.html Bye, bearophile
Re: duck!
On 10/17/2010 01:09 PM, Jeff Nowakowski wrote: On 10/16/2010 04:05 PM, Andrei Alexandrescu wrote: It's a subset of duck typing. I don't think calling a function that supports a limited form of duck typing "duck" is a lie. I'm sure if it was on a Go slide you would. Probably not in as strong terms, but if you want to point out that I'm biased... what can I do? I'm a simple man. Andrei
Re: duck!
On 10/16/2010 04:05 PM, Andrei Alexandrescu wrote: It's a subset of duck typing. I don't think calling a function that supports a limited form of duck typing "duck" is a lie. I'm sure if it was on a Go slide you would.
Re: duck!
On 10/17/2010 05:15 AM, kenji hara wrote:
I tried to arrange Duck-typing Patterns in D .
interface Quack
{
void quack();
}
class Duck : Quack
{
void quack(){...}
}
class Human
{
void quack(){...}
}
1. Static object type& static signature
[snip]
2. Static object type& structural signature
included in 5.
3. Static object type& dynamic signature
included in 6.
4. Dynamic object type& static signature
[snip]
5. Dynamic object type& static/structural signature
Quack q = adaptTo!Quack(new Duck());
q.quack();
q = adaptTo!Quack(new Human());
q.quack();
// The type of object referenced by q is dynamically chosen.
// --> Structural conformance with Quack, like Duck, Human.
// The type of variable q is statically chosen.
// --> Quack.
// Signature 'quack' statically chosen.
Currently, adaptTo supports this pattern.
Yup. Nice.
adaptTo realizes structural conformance through using static
conformance of interface.
It is belong to implementation decision.
6. Dynamic object type& dynamic signature
X x;
// x does not assume any signatures.
x = new Duck();
invoke(x, "quack"); // calls Duck.quack()
invoke(x, "undef"); // throws runtime-exception
// x can have like following templates:
// void opDispatch(string s)(){
// invoke(this, s);
// }
// By using this, X can convert static/structural signature to
dynamic one.
x.quack(); // calls Duck.quack()
x.udnef(); // throws runtime-exception
x = new Human();
x.quack(); // calls Human.quack()
invoke(x, "quack"); // calls Human.quack()
std.variant only supports part of this pattern, it is limited
operator overloading.
Implementing this needs runtime-reflection, so we can't support
this pattern perfectly in current D, since my sample code does not work.
Correct. Could you please submit the appropriate bug report(s) so this
is looked into?
Actually Variant can be made to support calls by using compile-time
reflection, as long as the type during assignment is known. Consider:
Variant v;
v = new Human;
At assignment time, v knows the static type of Human and can store a map
with "quack"'s signature. Later on, if you say v.quack(), the Variant
will access the map and find the right method.
The scenario that needs runtime reflection is this:
Variant v;
v = cast(Object) new Human;
At this point all static information is lost at assignment time.
'duck' may be funny, but not accurate.
P.S.
I researched interface in Go language.
(via http://golang.org/doc/go_for_cpp_programmers.html#Interfaces),
I think it is closest to 5 than others.
But it does not called 'Duck-Typing' or 'duck'.
http://www.google.com/search?as_q=duck+typing&hl=en&as_sitesearch=golang.org%2Fdoc%2F
Searching result in go-lang doc matches none.
I wouldn't want the creator of the facility himself to be unhappy about
the name. Here's a thought - I suggest we call your function simply
"adapt". Later on we might add an extra parameter to it that controls
strictness. Works?
Andrei
Re: duck!
On 10/17/2010 01:54 AM, lurker wrote:
Andrei Alexandrescu Wrote:
I was talking to Walter about Kenji's adaptTo. We both think it's a
very powerful enabler, but adaptTo is a bland name. After
discussing a few marketing strategies, I proposed "duck". It's
short, simple, and evokes "duck typing".
class C { int draw(){ return 10; } } interface Drawable { long
draw(); } ... auto c = new C; auto d = duck!Drawable(c);
Object c = new C; auto d = duck!Drawable(c); // awes
does this work? After all, c is a C:
Object c = new C; auto d = duck!Drawable(cast(C)c);
One fears this feature has little real world use. But it's a great
way to add additional bloat to the puny little Phobos...
It's amusing as always that the syntax is being discussed before we
even know how this works. How does the int -> long coercion work
there? Any possibility to get a written spec for this?
Fair point, but the discussion started as simply naming a
well-understood artifact. That was Kenji Hara's code here:
http://github.com/9rnsr/scrap/blob/master/interfaces/interfaces.d
Essentially what his function did was to offer a given interface on top
of an object (that did not implement the interface). The mechanism for
doing so was to generate simple forwarding functions.
From there, the discussion sprawled into defining different similar
functions, i.e. one that implements a given interface for a given object
on a best-effort basis and throws for non-matched methods.
Discussion also extended into a completely dynamic facility that
promises any method and uses runtime reflection (and exceptions) to
implement dynamic typing. It has been rightly pointed out that Variant
is the best type for that.
Once such functions will be integrated into Phobos, they will be
properly documented. I think it's okay to keep the discussion loosely
structured for now.
Andrei
Yeah... but what does adaptTo|duck|as do?
lurker napisał:
>> class C
>> {
>>int draw(){ return 10; }
>> }
>> interface Drawable
>> {
>>long draw();
>> }
>> ...
>> auto c = new C;
>> auto d = duck!Drawable(c);
>
> Object c = new C;
> auto d = duck!Drawable(c); // awes
>
> does this work? After all, c is a C:
I'd say no. c is an Object, you don't know it can draw().
> Object c = new C;
> auto d = duck!Drawable(cast(C)c);
Yeah, that's what you have to do.
> One fears this feature has little real world use. But it's a great way to
> add additional bloat to the puny little Phobos...
>
> It's amusing as always that the syntax is being discussed before we even
> know how this works. How does the int -> long coercion work there? Any
> possibility to get a written spec for this?
I got a similar feeling after seeing there's 70+ posts in this thread. There's
not even a link to the source to know what one is naming.
For one thing, I'd like to know whether (Duck|As|AdaptTo)!I is a class
implementing I or a struct mimicking I's API.
Or if in duck!I(a) a already implements I, does Duck alias itself away?
Or if in duck!I(a) a is a struct exposing I's methods (walks and quacks like
I), does Duck alias itself away?
What if I has an alias this to one of its properties?
What if I has static methods?
--
Tomek
Re: duck!
I tried to arrange Duck-typing Patterns in D .
interface Quack
{
void quack();
}
class Duck : Quack
{
void quack(){...}
}
class Human
{
void quack(){...}
}
1. Static object type & static signature
Duck d = new Duck;
d.quack();
// The type of object referenced by d is statically chosen.
// --> Duck,
// The type of variable d is statically chosen.
// --> Duck.
// Signature 'quack' statically chosen.
This is built-in-supported in D.
Using template like this is included in this pattern:
void f(T)(T t)
{
T.quack();
}
T and quack are bound statically.
2. Static object type & structural signature
included in 5.
3. Static object type & dynamic signature
included in 6.
4. Dynamic object type & static signature
Quack q = new Duck;
q.quack();
// The type of object referenced by q is dynamically chosen.
// --> extends Quack, like Duck,
// The type of variable q is statically chosen.
// --> Quack.
// Signature 'quack' statically chosen.
This is built-in-supported in D.
5. Dynamic object type & static/structural signature
Quack q = adaptTo!Quack(new Duck());
q.quack();
q = adaptTo!Quack(new Human());
q.quack();
// The type of object referenced by q is dynamically chosen.
// --> Structural conformance with Quack, like Duck, Human.
// The type of variable q is statically chosen.
// --> Quack.
// Signature 'quack' statically chosen.
Currently, adaptTo supports this pattern.
adaptTo realizes structural conformance through using static
conformance of interface.
It is belong to implementation decision.
6. Dynamic object type & dynamic signature
----
X x;
// x does not assume any signatures.
x = new Duck();
invoke(x, "quack"); // calls Duck.quack()
invoke(x, "undef"); // throws runtime-exception
// x can have like following templates:
// void opDispatch(string s)(){
// invoke(this, s);
// }
// By using this, X can convert static/structural signature to
dynamic one.
x.quack(); // calls Duck.quack()
x.udnef(); // throws runtime-exception
x = new Human();
x.quack(); // calls Human.quack()
invoke(x, "quack"); // calls Human.quack()
std.variant only supports part of this pattern, it is limited
operator overloading.
Implementing this needs runtime-reflection, so we can't support
this pattern perfectly in current D, since my sample code does not work.
'duck' may be funny, but not accurate.
P.S.
I researched interface in Go language.
(via http://golang.org/doc/go_for_cpp_programmers.html#Interfaces),
I think it is closest to 5 than others.
But it does not called 'Duck-Typing' or 'duck'.
http://www.google.com/search?as_q=duck+typing&hl=en&as_sitesearch=golang.org%2Fdoc%2F
Searching result in go-lang doc matches none.
Kenji Hara
Re: duck!
abram wrote: Walter Bright wrote: It reminds me of when a friend visited my house. After a very brief interval, he announced could tell it was a quality house, not a cheap facade. Intrigued, I asked him how. He said that the screw slots holding the wall plates on were all aligned the same way. It's a wholly irrelevant detail, added absolutely nothing to the function, but he said such attention to detail indicated the contractor cared about getting the details right. That reminds me of many a house I considered buying: what's behind those walls? Nuff said, but I'll go on. Are there rats in the cellar? Lead pipes? Asbestos? Walls cover it all. Show me what's under those walls and maybe you'll have a sale. Wait, that's the wrong "argument". Time out, regroup.: I would not buy anything "glossed over" (ref: engine compartments of cars people buy. Oh yes, they pressure wash them and give them a coat of laquer!). Yeah, but if they do a sloppy job on what shows, that doesn't bode well for what doesn't.
Re: duck!
On Saturday 16 October 2010 23:13:52 abram wrote: > Walter Bright wrote: > > Andrei Alexandrescu wrote: > >> Please substitute: "X does duck typing in the D programming > >> language". What is X? > >> > >> FWIW this was the story with "immutable". Walter got tired of > >> explaining: "Invariant implements immutable types in the D > >> programming language". > > > > Boy did I ever get tired of that. It's a classic example of names > > mattering - it's not just a bikeshed color. > > Maybe you should explain "bikeshed". Did someone steal your bike? From > your parent's shed? http://en.wiktionary.org/wiki/bikeshedding
Re: duck!
Andrei Alexandrescu Wrote:
> I was talking to Walter about Kenji's adaptTo. We both think it's a very
> powerful enabler, but adaptTo is a bland name. After discussing a few
> marketing strategies, I proposed "duck". It's short, simple, and evokes
> "duck typing".
>
> class C
> {
> int draw(){ return 10; }
> }
> interface Drawable
> {
> long draw();
> }
> ...
> auto c = new C;
> auto d = duck!Drawable(c);
Object c = new C;
auto d = duck!Drawable(c); // awes
does this work? After all, c is a C:
Object c = new C;
auto d = duck!Drawable(cast(C)c);
One fears this feature has little real world use. But it's a great way to add
additional bloat to the puny little Phobos...
It's amusing as always that the syntax is being discussed before we even know
how this works. How does the int -> long coercion work there? Any possibility
to get a written spec for this?
Re: duck!
Walter Bright wrote: > Kagamin wrote: >> Walter Bright Wrote: >>> One would think programmers are above all that, but we are not. >> >> Ask people what they think about "cross-platform" .net ad campaign. > > I don't know anything about that. Liar COM (and then some) guy.
Re: duck!
Walter Bright wrote: > Andrei Alexandrescu wrote: >> Please substitute: "X does duck typing in the D programming >> language". What is X? >> >> FWIW this was the story with "immutable". Walter got tired of >> explaining: "Invariant implements immutable types in the D >> programming language". > > Boy did I ever get tired of that. It's a classic example of names > mattering - it's not just a bikeshed color. Maybe you should explain "bikeshed". Did someone steal your bike? From your parent's shed?
Re: duck!
Andrei Alexandrescu wrote: > On 10/16/2010 12:38 PM, Steven Schveighoffer wrote: >> On Sat, 16 Oct 2010 13:19:36 -0400, Andrei Alexandrescu >> wrote: >> >>> The problem with "adaptTo" is that, just like itoa or printf, it is >>> too boring to have marketing value. >> >> Wait, really? This statement has no place in a programming language >> decision IMO. Nobody is going to start using D because it has a >> function *named* duck. >> >> Let's change writef to shazam! Let's call File BitLocker! And 'to' >> really should be called transformationVehicle! > > I think ducktype is an important feature of D. I want to give it a > name that is correspondingly resounding. The likes of files, writef, > and conversions are commonplace. That's all. > Sounds like an epitaph!
Re: duck!
Walter Bright wrote: > Andrei Alexandrescu wrote: >> On 10/16/2010 03:26 PM, Walter Bright wrote: >>> A lot of people do think duck typing is very important. >> It's the defining feature of Go. > > That makes me curious about the etymology of duckduckgo.com ! Sympathy plea?
Re: duck!
Walter Bright wrote: > It reminds me of when a friend visited my house. After a very brief > interval, he announced could tell it was a quality house, not a cheap > facade. Intrigued, I asked him how. He said that the screw slots > holding the wall plates on were all aligned the same way. It's a > wholly irrelevant detail, added absolutely nothing to the function, > but he said such attention to detail indicated the contractor cared > about getting the details right. That reminds me of many a house I considered buying: what's behind those walls? Nuff said, but I'll go on. Are there rats in the cellar? Lead pipes? Asbestos? Walls cover it all. Show me what's under those walls and maybe you'll have a sale. Wait, that's the wrong "argument". Time out, regroup.: I would not buy anything "glossed over" (ref: engine compartments of cars people buy. Oh yes, they pressure wash them and give them a coat of laquer!).
Re: duck!
On 2010-10-16 22:02:35 -0400, Leandro Lucarella said: I agree that "nametwo" is useless, but what you're proposing is plain dynamic typing, not duck typing. Duck-typing is what Go (and adaptTo) does. In dynamic languages you have to check for the methods existence at runtime just because is the only way to do it, but if you want to use a duck, you *need* to know that the object you're working with *can* quack(). That doesn't make dynamic typing a bad idea, it can be useful, but please don't name it "ducktype" as Andrei suggested. What Go does is not duck typing, it's structural typing. It clearly has some of the benefits of duck typing and thus shares some similarities with it, but it's not the same. <http://en.wikipedia.org/wiki/Structural_typing> In my argumentation, I try to stick to Wikipedia's definition of duck typing: <http://en.wikipedia.org/wiki/Duck_typing> In computer programming with object-oriented programming languages, duck typing is a style of dynamic typing in which an object's current set of methods and properties determines the valid semantics, rather than its inheritance from a particular class or implementation of a specific interface. [...] In duck typing, one is concerned with just those aspects of an object that are used, rather than with the type of the object itself. [...] Duck typing is aided by habitually not testing for the type of arguments in method and function bodies, relying on documentation, clear code, and testing to ensure correct use. Users of statically typed languages new to dynamically typed languages are usually tempted to add such static (before run-time) type checks, defeating the benefits and flexibility of duck typing, and constraining the language's dynamism. Read twice that last sentence. Clearly, statically implementing an interface is not what duck-typing is about. It could perhaps qualify as some sort structural typing, but it's better known as the adapter pattern. <http://en.wikipedia.org/wiki/Adapter_pattern> -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: duck!
Michel Fortin, el 16 de octubre a las 18:19 me escribiste:
> On 2010-10-16 17:45:56 -0400, Andrei Alexandrescu
> said:
>
> >unittest
> >{
> > auto x = new Drawable;
> > auto a = nameone!Widget(x); // works
> > //auto b = nameone!ColoredWidget(x); // doesn't compile
> > auto c = nametwo!ColoredWidget(x);
> > c.draw(); // works
> > c.setColor(red); // throws NotImplemented during runtime
> >}
> >
> >"nameone" implements Kenji's current code. "nametwo" is the looser
> >form of duck typing: whatever methods match will work, and the
> >rest are implemented to throw during runtime.
>
> What you're proposing above is just useless, and I'm honestly quite
> surprised you don't realize that.
>
> The real duck type almost already exists in Phobos, and it's called
> a variant. The only problem with it is that it is powerless when it
> comes to calling functions without casting it's content to a type
> first. Make it so this code can run and then you'll have implemented
> duck typing for real:
>
> class Duck { void quack(); }
> Variant v = new Duck;
> v.quack();
>
> Well, mostly. It could also be argued that this too should work too:
>
> Variant v = cast(Object)(new Duck);
> v.quack();
>
> but that'd require runtime reflexion as part of ClassInfo.
I agree that "nametwo" is useless, but what you're proposing is plain
dynamic typing, not duck typing. Duck-typing is what Go (and adaptTo)
does. In dynamic languages you have to check for the methods existence
at runtime just because is the only way to do it, but if you want to use
a duck, you *need* to know that the object you're working with *can*
quack().
That doesn't make dynamic typing a bad idea, it can be useful, but
please don't name it "ducktype" as Andrei suggested.
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
Sometimes I think the sure sign that life exists elsewhere in the universe
Is that that none of them tried to contact us
Re: duck!
Andrei Alexandrescu, el 16 de octubre a las 19:19 me escribiste: > >I hate myself, I just keep replying when I know this matter is closed, > >if both you and Andrei like something, is a dead end for any > >alternatives... > > > >Well, at least I will be able to say "I tried"... > > How about this: we call "adapt" the strict adaptation of one > interface to another and "ducktype" the loose adaptation that might > fail dynamically. Would that float your boat? I don't find it ideal, but it's definitely better. What I don't get is what the purpose/use of "ducktype" in D. And why do you even have to pass a type to ducktype? If you aren't certain if the object implements a function or not, that's not really duck-typing either, that's just dynamic typing and in that case, why do you even bother to specify an interface? I really don't see a point to it... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- at ease, eating well (no more microwave dinners and saturated fats), a patient better driver, a safer car (baby smiling in back seat), sleeping well (no bad dreams), no paranoia,
Re: duck!
On 10/16/2010 07:50 PM, Denis Koroskin wrote:
On Sun, 17 Oct 2010 04:17:18 +0400, Andrei Alexandrescu
wrote:
On 10/16/2010 05:57 PM, kenji hara wrote:
Current dmd does not enough support runtime reflection.
[snip]
I think runtime reflection is not needed. What you'd need to do for
the "loose duck" is generate code that throws for all interface
methods that are not present in the class. Am I wrong?
Andrei
interface ICanQuack
{
void quack() { ... }
}
class Duck
{
void quack() { .. }
}
Object o = new Duck();
Duck d = duck!(ICanQuack)(o);
d.quack(); // throw or not?
Throw... but now I see what Kenji meant. Thanks! So really there's three
levels:
- statically-enforced conformance
- statically-decided conformance
- dynamically-decided conformance
Now we have three names to find, not one :o).
Andrei
Re: duck!
On Sun, 17 Oct 2010 04:17:18 +0400, Andrei Alexandrescu
wrote:
On 10/16/2010 05:57 PM, kenji hara wrote:
Current dmd does not enough support runtime reflection.
[snip]
I think runtime reflection is not needed. What you'd need to do for the
"loose duck" is generate code that throws for all interface methods that
are not present in the class. Am I wrong?
Andrei
interface ICanQuack
{
void quack() { ... }
}
class Duck
{
void quack() { .. }
}
Object o = new Duck();
Duck d = duck!(ICanQuack)(o);
d.quack(); // throw or not?
Re: duck!
On 10/16/2010 05:18 PM, Leandro Lucarella wrote: Walter Bright, el 16 de octubre a las 11:16 me escribiste: Label it "adaptTo" and few will even notice it. Label it "duck" and people will click on the link to see what it does. It's important that people notice that D has these things, and "duck" helps with that. Well, maybe I'm not people, but I wouldn't click on anything named duck. And if you ask me, marketing is OK for a name product, but not for writing source code. You are putting marketing in the wrong place. I would hate to have to write meaningless code like: auto wow = buzz!Word(cool); I've been in this business a long time, and while you'd think that programmers are above "what's in a name", we are just like everyone else. A catchy name gets results. Borland, for example, added a trivial and boring feature to their linker, called it "smart linking", and managed to get an unbelievable amount of hoopla from the computer press out of it. They did it again with another feature they called "zoom". You are underestimating people, if your targets are morons, that's the kind of people you'll get in the community. Which blog article would you click on? "Interface Adapter for D" or "Duck Typing for D"? Probably "Duck typing for D", but why can't you name the function "adapt", "adaptTo" or "as" and the article "Duck typing for D"??? The article is the right place to do marketing and use cool names to get the attention, NOT THE CODE. "duck" is a great name for the feature. It's short& sweet, fits right in with the popularity of duck typing, stands out, isn't boring, etc. Heck, as proof, look at all the interest in this thread!! What you're saying now is just plain stupid: 1. A long thread generally indicated the presence of something controversial, not something good and accepted (those threads are usually short, or filled with just "+1"). 2. You can just post "hi" in this NG and get a thread of thousands of messages ;) I hate myself, I just keep replying when I know this matter is closed, if both you and Andrei like something, is a dead end for any alternatives... Well, at least I will be able to say "I tried"... How about this: we call "adapt" the strict adaptation of one interface to another and "ducktype" the loose adaptation that might fail dynamically. Would that float your boat? Andrei
Re: duck!
On 10/16/2010 05:57 PM, kenji hara wrote: Current dmd does not enough support runtime reflection. [snip] I think runtime reflection is not needed. What you'd need to do for the "loose duck" is generate code that throws for all interface methods that are not present in the class. Am I wrong? Andrei
Re: duck!
Walter Bright, el 16 de octubre a las 11:16 me escribiste: > Label it "adaptTo" and few will even notice it. Label it "duck" and > people will click on the link to see what it does. It's important > that people notice that D has these things, and "duck" helps with > that. Well, maybe I'm not people, but I wouldn't click on anything named duck. And if you ask me, marketing is OK for a name product, but not for writing source code. You are putting marketing in the wrong place. I would hate to have to write meaningless code like: auto wow = buzz!Word(cool); > I've been in this business a long time, and while you'd think that > programmers are above "what's in a name", we are just like everyone > else. A catchy name gets results. Borland, for example, added a > trivial and boring feature to their linker, called it "smart > linking", and managed to get an unbelievable amount of hoopla from > the computer press out of it. They did it again with another feature > they called "zoom". You are underestimating people, if your targets are morons, that's the kind of people you'll get in the community. > Which blog article would you click on? "Interface Adapter for D" or > "Duck Typing for D"? Probably "Duck typing for D", but why can't you name the function "adapt", "adaptTo" or "as" and the article "Duck typing for D"??? The article is the right place to do marketing and use cool names to get the attention, NOT THE CODE. > "duck" is a great name for the feature. It's short & sweet, fits > right in with the popularity of duck typing, stands out, isn't > boring, etc. Heck, as proof, look at all the interest in this > thread!! What you're saying now is just plain stupid: 1. A long thread generally indicated the presence of something controversial, not something good and accepted (those threads are usually short, or filled with just "+1"). 2. You can just post "hi" in this NG and get a thread of thousands of messages ;) I hate myself, I just keep replying when I know this matter is closed, if both you and Andrei like something, is a dead end for any alternatives... Well, at least I will be able to say "I tried"... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- "All mail clients suck. This one just sucks less." -me, circa 1995
Re: duck!
Current dmd does not enough support runtime reflection.
// test code
class A
{
int quack() { return 10; }
}
void main()
{
Object o = new A();
TypeInfo ti;
ti = typeid(o);
if( auto ti_c = cast(TypeInfo_Class)ti ){
auto members = ti_c.getMembers("quack");
assert(members !is null); // --> failed!!
foreach( mi; members ){
if( auto mi_fn = cast(MemberInfo_function)mi ){
assert(mi_fn.name == "quack");
auto fp = mi_fn.fp;
auto ti_fn = mi_fn.typeInfo;
//...
}
}
}
}
Kenji Hara.
2010/10/17 Andrei Alexandrescu :
> On 10/16/2010 03:30 PM, Michel Fortin wrote:
>>
>> On 2010-10-16 16:05:52 -0400, Andrei Alexandrescu
>> said:
>>
>>> On 10/16/2010 02:54 PM, kenji hara wrote:
>>>>
>>>> Adapter-Pattern! I'd have forgotten the name.
>>>> It is NOT equals to duck-typing.
>>>
>>> It's a subset of duck typing. I don't think calling a function that
>>> supports a limited form of duck typing "duck" is a lie.
>>
>> Not a lie, just a word with a deceptive meaning that'll lead people to
>> believe something else than the truth. Some cynically call that
>> marketing speech.
>
> As Walter said, that's probably why he, you, and myself aren't marketers.
>
>> In my opinion, a duck type in D should be a variant that allows you to
>> call all the functions of the underlying object, and throws (at runtime)
>> when no matching function is found. I think you'll agree with me that
>> this is very far from the adapter pattern.
>
> In fact I had this idea while running:
>
> interface Widget
> {
> void draw();
> void move(int x, int y);
> }
>
> interface ColoredWidget : Widget
> {
> void setColor(Color c);
> }
>
> class Drawable
> {
> void draw();
> void move(int x, int y);
> }
>
> unittest
> {
> auto x = new Drawable;
> auto a = nameone!Widget(x); // works
> //auto b = nameone!ColoredWidget(x); // doesn't compile
> auto c = nametwo!ColoredWidget(x);
> c.draw(); // works
> c.setColor(red); // throws NotImplemented during runtime
> }
>
> "nameone" implements Kenji's current code. "nametwo" is the looser form of
> duck typing: whatever methods match will work, and the rest are implemented
> to throw during runtime.
>
> Question is, of course, figuring out good substitutes for nameone and
> nametwo.
>
> Kenji, do you think you could also implement nametwo?
>
>
> Andrei
>
Re: duck!
On Saturday 16 October 2010 15:06:21 Walter Bright wrote: > Andrei Alexandrescu wrote: > > On 10/16/2010 03:26 PM, Walter Bright wrote: > >> A lot of people do think duck typing is very important. > > > > It's the defining feature of Go. > > That makes me curious about the etymology of duckduckgo.com ! I think that it's supposed to come from duck duck goose. - Jonathan M Davis
Re: duck!
Steven Schveighoffer wrote: I'm just saying that marketability of D does not change no matter what appropriate term you choose. And this is our fundamental disagreement. I think the choices of names matters a lot. If names don't matter, why not name your son "Sue" ? :-) But were there functions named zoomTechnology() and smartLink()? Were their tools named zoom or smartl or something? Is that what pushed them over the edge, or was it the bullet on the packaging that said: * Includes zoom technology! I don't believe that there is any fundamental difference between the name of a function and the name of the technology. But people don't search google for "duck typing programming languages" and pick the language they're going to use from this list! They may very well search "duck typing in the D programming language". Heck, that's what I do when I'm investigating whether language X supports feature Y. I do it a lot. I think you are really going cuckoo over this feature like it's the best thing since ranges, and I don't see it being that. I am happy with the name ranges for what it does, I think it's exactly right. Am I going cuckoo over this one? Perhaps. But I also believe that even getting the small details right is important. It reminds me of when a friend visited my house. After a very brief interval, he announced could tell it was a quality house, not a cheap facade. Intrigued, I asked him how. He said that the screw slots holding the wall plates on were all aligned the same way. It's a wholly irrelevant detail, added absolutely nothing to the function, but he said such attention to detail indicated the contractor cared about getting the details right. Invariant vs. immutable is not the same as adaptTo vs. duck. Invariant already had a meaning in D1, and when choosing a new name, it was logical to use immutable. Is immutable an 'exciting marketing term'? No, it's as boring as they come. But it's definitely the best term for the job. Let's focus on choosing the best term for what 'adaptTo' does, and when we market that D does duck typing in an article or a list of features (that shows up on google), we can include all the features of D that do duck typing. With invariant I *always* had to explain it (even to people with no knowledge of the D1 meaning), and people would looked puzzled even after the explanation. With immutable, I stopped having to explain it. The name change was a big win.
Re: duck!
On 2010-10-16 17:45:56 -0400, Andrei Alexandrescu
said:
unittest
{
auto x = new Drawable;
auto a = nameone!Widget(x); // works
//auto b = nameone!ColoredWidget(x); // doesn't compile
auto c = nametwo!ColoredWidget(x);
c.draw(); // works
c.setColor(red); // throws NotImplemented during runtime
}
"nameone" implements Kenji's current code. "nametwo" is the looser form
of duck typing: whatever methods match will work, and the rest are
implemented to throw during runtime.
What you're proposing above is just useless, and I'm honestly quite
surprised you don't realize that.
The real duck type almost already exists in Phobos, and it's called a
variant. The only problem with it is that it is powerless when it comes
to calling functions without casting it's content to a type first. Make
it so this code can run and then you'll have implemented duck typing
for real:
class Duck { void quack(); }
Variant v = new Duck;
v.quack();
Well, mostly. It could also be argued that this too should work too:
Variant v = cast(Object)(new Duck);
v.quack();
but that'd require runtime reflexion as part of ClassInfo.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: duck!
Andrei Alexandrescu wrote: On 10/16/2010 03:26 PM, Walter Bright wrote: A lot of people do think duck typing is very important. It's the defining feature of Go. That makes me curious about the etymology of duckduckgo.com !
Re: duck!
The very important principle here for the naming is making it obvious that D supports an element of duck-typing. Naming it duck! does just that. Advertisability is not what I would use to describe it. How about clarity, articulateness, and lucidity? On Sat, Oct 16, 2010 at 4:52 PM, Michael Chen wrote: > totally agreeed. let advertisability to influence a function name is > ridiculous to me. you gotta have some princeple for names, but > advertisability? i dont think so.
Re: duck!
Steven Schveighoffer wrote: On Sat, 16 Oct 2010 16:31:34 -0400, Walter Bright wrote: If I google for "adapt for D" I'll get a hopeless mess of irrelevant links. "duck typing for D" should be much better. Remember that google ranks pages by relevance, and searching for "duck" will give higher ranking for pages with "duck" in the url, title, headings, etc. That's just what we want. And it should come up with the page on digitalmars.com titled 'duck typing in D' which describes how to use templates or the adaptTo type to achieve duck typing. When writing fiction, it's a good idea to constantly shift which words used to describe something. But when writing tech manuals, and when making things search engine friendly, it pays to use a single term and use it consistently. For example, once upon a time I read some article on arrays, and it variously referred to the array "elements", "entries", and "values". Really, that sucked, as the reader was left being not quite sure if they meant the same thing or not. If you expect people to search for "duck typing" (and I do) then why stick another level of indirection? Call it a "duck". When you find yourself constantly saying "duck typing: see adaptTo", then you named it wrong.
Re: duck!
On 10/16/2010 04:52 PM, Michael Chen wrote: totally agreeed. let advertisability to influence a function name is ridiculous to me. you gotta have some princeple for names, but advertisability? i dont think so. It is a function, but it implements an entire feature - like e.g. "cast". What if D has casting but called it e.g. "force"? I'm looking for a name that is descriptive and evocative. Andrei
Re: duck!
On 10/16/2010 04:00 PM, Steven Schveighoffer wrote: But naming the function that does duck typing 'duck' doesn't seem to me like it makes or breaks D at all. You do find it important, otherwise you wouldn't have spent cumulative hours arguing about it. Andrei
Re: duck!
totally agreeed. let advertisability to influence a function name is ridiculous to me. you gotta have some princeple for names, but advertisability? i dont think so. On Sunday, October 17, 2010, Steven Schveighoffer wrote: > On Sat, 16 Oct 2010 16:26:15 -0400, Walter Bright > wrote: > > > Steven Schveighoffer wrote: > > Think of it another way. Remember zip files? What a great name, and yes, it > seemed silly at first, but zip entered the lexicon and D has a zip module and > it never occurs to anyone it might be better named std.compressedArchive. > Phil Katz renamed arc files "zip" files, called his compressor "pkzip" and > blew away arc so badly that most people are unaware it even existed. > > I think the catchy, silly "zip" name was a significant factor in getting > people to notice his program. In contrast, the superior "lharc" with its > "lzh" files never caught on. > > These are completely unsubstantiated statements focused on a very narrow set > of variables. It's like all those studies that say X causes cancer because > look most people who use X have cancer. Well, yeah, but they are all 40-70 > yr old people, who freaking knows how many factors went into them getting > cancer!!! And it proves itself again and again when the next year, they say, > 'well that study was flawed, we now *know* that it was really Y'. > > > It's an example of a phenomenon I've seen over and over. How about the names > Google and Yahoo? Boy did I think they were stupid names for companies and > products. Boy was I wrong. How about the perjorative name "twitter" and the > hopelessly undignified verb "tweet"? I still can't bring myself to say I > "tweeted". Ugh. > > > This is called cherry picking. What about microsoft, IBM, apple, gillette, > DOS, etc. All these names aren't "wacky", yet they are still successful. > How do you explain that? You might lump GoDaddy.com as one of those 'wacky' > names that made it, but that has nothing to do with it. > > Google and Yahoo succeeded because their product was good. D will succeed > because it does duck typing, not because the function that does duck typing > is called 'duck'. Now, if D was all about duck typing, and you called it > 'ducky', then I think that the name might be appropriate, and actually help > with marketing. But naming the function that does duck typing 'duck' doesn't > seem to me like it makes or breaks D at all. I want to be clear that duck is > not my first choice, but it's certainly a name that makes sense. I'm just > saying that marketability of D does not change no matter what appropriate > term you choose. > > > I also couldn't believe all the mileage Borland got out of naming minor > features "zoom technology" and "smart linking". So I don't buy that we > programmers are above all that. > > > But were there functions named zoomTechnology() and smartLink()? Were their > tools named zoom or smartl or something? Is that what pushed them over the > edge, or was it the bullet on the packaging that said: > > * Includes zoom technology! > > > > "duck" *is* indicative of what the feature does, and so it is a lot better > than "zoom" or "smart" or "yahoo", which I'd have a hard time justifying. I > guess that's why I'm not a marketer! > > > Yes, duck is a valid option. And the fact that duck typing is what it does > is a very good reason to use it. I just don't see 'marketing draw' as being > a factor whatsoever. It's useless noise. > > > Besides, duck isn't the compiler name, it's a very very small part of the > library. I think you associate more weight to this than there actually is. > > > A lot of people do think duck typing is very important. > > > And D already does duck typing. Templates do duck typing. 'adaptTo' does it > too, and it's cool, but it's not *that* important (no offense, Kenji). > > > Let's concentrate on finding the name that best describes the function. This > might be 'duck', but let's leave marketing considerations out of it. If duck > was a verb that meant 'walk like a...' then I'd agree it was a fine term. > How about if we can say D's functions are named intuitively instead of after > some colloquial term that describes the function? > And yeah, I agree zip is now a de-facto term, so much so that I think > std.range.Zip should be renamed :) But was it z
Re: duck!
On 10/16/2010 03:58 PM, Rainer Deyke wrote: On 10/16/2010 14:02, Walter Bright wrote: If it's a cringeworthy name, I'd agree. But "duck" is not cringeworthy. Fact: I cringe every time I hear "duck typing". Me too, for a long time. Then I had to get used to it because most everybody was using it. Andrei
Re: duck!
On 10/16/2010 03:43 PM, kenji hara wrote: Yes, it certainly is not a lie. In Naming Type System, adaptTo extends duck. But, people who you want to appeal it will think that all of duck-typings each person imagine possible. As a result, by knowing duck supports only Adapter-Pattern, they will be lied to and angry. It will negatively affect D. D also has duck-typing by template, so naming adaptTo duck will be making ambiguous situations. (Like Tuple and TypeTuple) Please reconsider it. Kenji. One way to go would be to implement the looser form of duck typing under the name "duck" and the current stricter variant under the name "adapt". (See my previous message.) Andrei
Re: duck!
On 10/16/2010 03:30 PM, Michel Fortin wrote:
On 2010-10-16 16:05:52 -0400, Andrei Alexandrescu
said:
On 10/16/2010 02:54 PM, kenji hara wrote:
Adapter-Pattern! I'd have forgotten the name.
It is NOT equals to duck-typing.
It's a subset of duck typing. I don't think calling a function that
supports a limited form of duck typing "duck" is a lie.
Not a lie, just a word with a deceptive meaning that'll lead people to
believe something else than the truth. Some cynically call that
marketing speech.
As Walter said, that's probably why he, you, and myself aren't marketers.
In my opinion, a duck type in D should be a variant that allows you to
call all the functions of the underlying object, and throws (at runtime)
when no matching function is found. I think you'll agree with me that
this is very far from the adapter pattern.
In fact I had this idea while running:
interface Widget
{
void draw();
void move(int x, int y);
}
interface ColoredWidget : Widget
{
void setColor(Color c);
}
class Drawable
{
void draw();
void move(int x, int y);
}
unittest
{
auto x = new Drawable;
auto a = nameone!Widget(x); // works
//auto b = nameone!ColoredWidget(x); // doesn't compile
auto c = nametwo!ColoredWidget(x);
c.draw(); // works
c.setColor(red); // throws NotImplemented during runtime
}
"nameone" implements Kenji's current code. "nametwo" is the looser form
of duck typing: whatever methods match will work, and the rest are
implemented to throw during runtime.
Question is, of course, figuring out good substitutes for nameone and
nametwo.
Kenji, do you think you could also implement nametwo?
Andrei
Re: duck!
On 10/16/2010 03:26 PM, Walter Bright wrote: It's an example of a phenomenon I've seen over and over. How about the names Google and Yahoo? Boy did I think they were stupid names for companies and products. Boy was I wrong. How about the perjorative name "twitter" and the hopelessly undignified verb "tweet"? I still can't bring myself to say I "tweeted". Ugh. I also couldn't believe all the mileage Borland got out of naming minor features "zoom technology" and "smart linking". So I don't buy that we programmers are above all that. C++ credits a lot of its early success to provide "class" which is essentially a synonym to "struct". Technically it wasn't even necessary with that semantics, yet everybody wet their pants when they saw the keyword. "duck" *is* indicative of what the feature does, and so it is a lot better than "zoom" or "smart" or "yahoo", which I'd have a hard time justifying. I guess that's why I'm not a marketer! Besides, duck isn't the compiler name, it's a very very small part of the library. I think you associate more weight to this than there actually is. A lot of people do think duck typing is very important. It's the defining feature of Go. Andrei
Re: duck!
On Sat, 16 Oct 2010 16:31:34 -0400, Walter Bright wrote: If I google for "adapt for D" I'll get a hopeless mess of irrelevant links. "duck typing for D" should be much better. Remember that google ranks pages by relevance, and searching for "duck" will give higher ranking for pages with "duck" in the url, title, headings, etc. That's just what we want. And it should come up with the page on digitalmars.com titled 'duck typing in D' which describes how to use templates or the adaptTo type to achieve duck typing. -Steve
Re: duck!
On Sat, 16 Oct 2010 16:26:15 -0400, Walter Bright wrote: Steven Schveighoffer wrote: Think of it another way. Remember zip files? What a great name, and yes, it seemed silly at first, but zip entered the lexicon and D has a zip module and it never occurs to anyone it might be better named std.compressedArchive. Phil Katz renamed arc files "zip" files, called his compressor "pkzip" and blew away arc so badly that most people are unaware it even existed. I think the catchy, silly "zip" name was a significant factor in getting people to notice his program. In contrast, the superior "lharc" with its "lzh" files never caught on. These are completely unsubstantiated statements focused on a very narrow set of variables. It's like all those studies that say X causes cancer because look most people who use X have cancer. Well, yeah, but they are all 40-70 yr old people, who freaking knows how many factors went into them getting cancer!!! And it proves itself again and again when the next year, they say, 'well that study was flawed, we now *know* that it was really Y'. It's an example of a phenomenon I've seen over and over. How about the names Google and Yahoo? Boy did I think they were stupid names for companies and products. Boy was I wrong. How about the perjorative name "twitter" and the hopelessly undignified verb "tweet"? I still can't bring myself to say I "tweeted". Ugh. This is called cherry picking. What about microsoft, IBM, apple, gillette, DOS, etc. All these names aren't "wacky", yet they are still successful. How do you explain that? You might lump GoDaddy.com as one of those 'wacky' names that made it, but that has nothing to do with it. Google and Yahoo succeeded because their product was good. D will succeed because it does duck typing, not because the function that does duck typing is called 'duck'. Now, if D was all about duck typing, and you called it 'ducky', then I think that the name might be appropriate, and actually help with marketing. But naming the function that does duck typing 'duck' doesn't seem to me like it makes or breaks D at all. I want to be clear that duck is not my first choice, but it's certainly a name that makes sense. I'm just saying that marketability of D does not change no matter what appropriate term you choose. I also couldn't believe all the mileage Borland got out of naming minor features "zoom technology" and "smart linking". So I don't buy that we programmers are above all that. But were there functions named zoomTechnology() and smartLink()? Were their tools named zoom or smartl or something? Is that what pushed them over the edge, or was it the bullet on the packaging that said: * Includes zoom technology! "duck" *is* indicative of what the feature does, and so it is a lot better than "zoom" or "smart" or "yahoo", which I'd have a hard time justifying. I guess that's why I'm not a marketer! Yes, duck is a valid option. And the fact that duck typing is what it does is a very good reason to use it. I just don't see 'marketing draw' as being a factor whatsoever. It's useless noise. Besides, duck isn't the compiler name, it's a very very small part of the library. I think you associate more weight to this than there actually is. A lot of people do think duck typing is very important. And D already does duck typing. Templates do duck typing. 'adaptTo' does it too, and it's cool, but it's not *that* important (no offense, Kenji). Let's concentrate on finding the name that best describes the function. This might be 'duck', but let's leave marketing considerations out of it. If duck was a verb that meant 'walk like a...' then I'd agree it was a fine term. How about if we can say D's functions are named intuitively instead of after some colloquial term that describes the function? And yeah, I agree zip is now a de-facto term, so much so that I think std.range.Zip should be renamed :) But was it zip that made the tool famous or the tool that made zip famous? Let's also not forget the hundreds, probably thousands, of 'cute' names that didn't save their respective products because the marketing material sucked. I think 'zip' got peoples' attention, and then pkzip delivered the goods (better than arc). lharc, on the other hand, had a ponderous name and failed despite being significantly better. So yeah, I think the name got pkzip on the map, but yes, the product also had to deliver. A cute name is not enough to save a cra
Re: duck!
On 10/16/2010 14:02, Walter Bright wrote: > If it's a cringeworthy name, I'd agree. But "duck" is not cringeworthy. Fact: I cringe every time I hear "duck typing". -- Rainer Deyke - rain...@eldwood.com
Re: duck!
I'm going to go with duck on this one. It could be an attractive name to put in reddit/yc titles.. "Can your language duck? D can, with duck!". Plus it's easily greppable and easy to type. And I don't like stuttering words like adaptTo, there's two repeating t's in there *and* I need a shift, that is an outrage! Not every word in the language/lib has to be dead-serious. :) On 10/16/10, Walter Bright wrote: > Lutger wrote: >> Justin Johansson wrote: >> >>> On 16/10/2010 6:30 PM, Christof Schardt wrote: >>>>> auto d = duck!Drawable(c); // awes >>>> What about "as" ? >>>> >>>> auto d = as!Drawable(c); >>>> >>>> Christof >>> This is a totally brilliant suggestion by Christof as >>> anyone who understands the XPath 2.0 type language >>> would tell you also. >>> >>> While finding duck! rather cute, marketing intelligence >>> will confirm that Christof's as! suggestion is the way to go. >>> >>> I feel woeful that I did not think of it myself. Award >>> for naming suggestion definitely goes to Christof. >>> >>> Justin >> >> plus, it's shorter to type. >> >> *ducks* > > Try googling "as for D" >
Re: duck!
Yes, it certainly is not a lie. In Naming Type System, adaptTo extends duck. But, people who you want to appeal it will think that all of duck-typings each person imagine possible. As a result, by knowing duck supports only Adapter-Pattern, they will be lied to and angry. It will negatively affect D. D also has duck-typing by template, so naming adaptTo duck will be making ambiguous situations. (Like Tuple and TypeTuple) Please reconsider it. Kenji. 2010/10/17 Andrei Alexandrescu : > On 10/16/2010 02:54 PM, kenji hara wrote: >> >> Adapter-Pattern! I'd have forgotten the name. >> It is NOT equals to duck-typing. > > It's a subset of duck typing. I don't think calling a function that supports > a limited form of duck typing "duck" is a lie. > > Andrei > >
