digitalmars.D - x.sizeof vs typeid(x)
- Sergey Gromov (4/4) Feb 05 2008 I wonder why .sizeof is implemented as a property while typeof() and
- Janice Caron (4/8) Feb 05 2008 I believe there are plans afoot to remove the distinction, so that
- Sergey Gromov (9/19) Feb 06 2008 Are you sure this is to the better ? I'm not quite fond of D's freedom
- bearophile (10/11) Feb 06 2008 But that may be false if you take lot of care of keeping the language ti...
- Matti Niemenmaa (13/27) Feb 06 2008 The point is that it shouldn't matter. If you want to change it later to...
- bearophile (4/9) Feb 06 2008 I was talking about free functions. I think for methods/properties the s...
- Matti Niemenmaa (5/7) Feb 06 2008 As I said in another post, that which applies to properties applies equa...
- Robert Fraser (4/22) Feb 06 2008 I agree with you on that particular syntax. I think when it's a member
- Matti Niemenmaa (4/7) Feb 06 2008 The argument for class properties applies equally well to global variabl...
- Robert Fraser (3/10) Feb 06 2008 Oops, forgot about those... alright, well I guess then people just need
- torhu (5/16) Feb 06 2008 I've actually used that when making bindings for a C library which has
- Christian Kamm (7/15) Feb 06 2008 It really gets odd when foo is a function as well:
- Sergey Gromov (10/19) Feb 06 2008 Agree. If there were, say, an attribute `property', so that you can
- Sergey Gromov (7/13) Feb 06 2008 Or even forbid to use the `double()' syntax for properties, and forbid
- Robert Fraser (15/28) Feb 06 2008 From my limited experience with C#, I know there's some kind of special...
- bearophile (4/6) Feb 06 2008 If you take a look at my last post of notes (the 4th) you can see I sugg...
- Sergey Gromov (5/22) Feb 06 2008 Yes, this would be far more consistent of course. I've just tried to
- downs (5/12) Feb 06 2008 I just don't like "});". The less closing parens the better. :)
- Tom S (14/18) Feb 07 2008 And when I actually asked for comments about that syntax, no one stated
- Sergey Gromov (16/31) Feb 07 2008 I don't know where or when you have asked for this. It's not my job to
- Tom S (28/42) Feb 07 2008 Ah, fine then, I thought you saw me pasting a more complete example on
- Sergey Gromov (18/34) Feb 07 2008 OK so I'm new to D, too. It's a part of a problem. I have quite strong...
- Tom S (23/39) Feb 07 2008 Well then, the whole C++ committee is following bad practice as well, by...
- Sergey Gromov (8/50) Feb 07 2008 What can I say. I do not agree. C++ committee is not the best
- Anders Bergh (5/10) Feb 07 2008 How is this different from other code? You have to look in any
- Sergey Gromov (8/18) Feb 08 2008 If there is a bug, and I know it's /not/ in the OpenGL sub-system, and I...
- Alexander Panek (4/10) Feb 08 2008 Uhm.. you consider code error-prone because you can't parse it in your
- Sergey Gromov (6/16) Feb 08 2008 Don't you see the difference between "it is" and "I consider" ? If I'm
- Alexander Panek (2/17) Feb 08 2008 Are there bugs in there?
- Tom S (16/21) Feb 07 2008 As long as you understand the language, you should understand more or
- bearophile (8/10) Feb 08 2008 Right, a committee too can take bad choices, that operator usage is very...
- Tom S (23/35) Feb 08 2008 You've also stated that the programmer doesn't have to understand what's...
- bearophile (6/7) Feb 08 2008 I think all I have said was "I agree" :-) So I can explain a bit better.
- Walter Bright (3/7) Feb 06 2008 Because expression.identifier always yields an expression, whereas
- Robert Fraser (2/10) Feb 06 2008 typeid yeilds an expression...
- Walter Bright (4/16) Feb 06 2008 The subject says typeid, the post says typeof !
- Christopher Wright (2/9) Feb 07 2008 real.nan?
- Walter Bright (2/12) Feb 07 2008 Yields an expression, not a type.
- Christopher Wright (2/15) Feb 08 2008 typeid yields an expression, not a type.
- Moritz Warning (7/16) Feb 06 2008 From a users perspective, my first thought is always that it should be
I wonder why .sizeof is implemented as a property while typeof() and typeid() are functions. I can see no reasons for such inconsistency. It's not that obvious for typeof() because it yields a type instead of a value, but even then, why not ?
Feb 05 2008
I believe there are plans afoot to remove the distinction, so that f(x) and x.f are, in general, interchangable. If and when that day comes, perhaps we'll be able to write sizeof(x) and x.typeid as well? On 06/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:I wonder why .sizeof is implemented as a property while typeof() and typeid() are functions. I can see no reasons for such inconsistency. It's not that obvious for typeof() because it yields a type instead of a value, but even then, why not ?
Feb 05 2008
Are you sure this is to the better ? I'm not quite fond of D's freedom in syntax. It already allows to write an unreadable code like this: use(context) in (GL gl) {draw(gl);} auto GetEven = stackthread = (int delegate() read, void delegate(int) yield) {...} Less typing is often => less maintainable. And Perl's slogan, "there is more than one way to do things," is exactly what makes Perl a write-only language. SnakE Janice Caron Wrote:I believe there are plans afoot to remove the distinction, so that f(x) and x.f are, in general, interchangable. If and when that day comes, perhaps we'll be able to write sizeof(x) and x.typeid as well? On 06/02/2008, Sergey Gromov <snake.scaly gmail.com> wrote:I wonder why .sizeof is implemented as a property while typeof() and typeid() are functions. I can see no reasons for such inconsistency. It's not that obvious for typeof() because it yields a type instead of a value, but even then, why not ?
Feb 06 2008
Sergey Gromov:Less typing is often => less maintainable.But that may be false if you take lot of care of keeping the language tidy, quite ergonomic. Python is quite maintainable, and it's far from being verbose. Haskell too is readable enough, if you know it, despite its programs being quite short. In this regard, one of the things I don't like of D syntax is that it allows to call functions without the final () if they take no arguments. It may be useful for properties, but when you see something like: foo = bar; Is it a function call? I am learning to always put the () there to be explicit: foo = bar(); To improve code readability I think it may be better to remove this feature from the language (and later that may be used to simplify the object instantiation syntax). Bye, bearophile
Feb 06 2008
bearophile wrote:In this regard, one of the things I don't like of D syntax is that it allows to call functions without the final () if they take no arguments. It may be useful for properties, but when you see something like: foo = bar; Is it a function call? I am learning to always put the () there to be explicit: foo = bar(); To improve code readability I think it may be better to remove this feature from the language (and later that may be used to simplify the object instantiation syntax).The point is that it shouldn't matter. If you want to change it later to a function, you have to change all the points where you use it as well. Canonical example with classes: class Vector { Point a, b; double distance; this(...) {...} } Now, if you want to save memory by changing distance to a method instead: class Vector { Point a, b; this(...) {...} double distance() {...} } You would have to change all uses of distance, whether inside or outside the class, to be distance() instead of distance. Except that D does give us the ability to always use just distance and not care about whether it's a function or not. -- E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Feb 06 2008
Matti Niemenmaa:You would have to change all uses of distance, whether inside or outside the class, to be distance() instead of distance. Except that D does give us the ability to always use just distance and not care about whether it's a function or not.I was talking about free functions. I think for methods/properties the syntax without () can be kept... Bye, bearophile
Feb 06 2008
bearophile wrote:I was talking about free functions. I think for methods/properties the syntax without () can be kept...As I said in another post, that which applies to properties applies equally well to free functions, due to global variables. -- E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Feb 06 2008
bearophile wrote:Sergey Gromov:I agree with you on that particular syntax. I think when it's a member of some sort, that syntax should be allowed, though (to allow a property syntax), but for free functions it's a bad idea.Less typing is often => less maintainable.But that may be false if you take lot of care of keeping the language tidy, quite ergonomic. Python is quite maintainable, and it's far from being verbose. Haskell too is readable enough, if you know it, despite its programs being quite short. In this regard, one of the things I don't like of D syntax is that it allows to call functions without the final () if they take no arguments. It may be useful for properties, but when you see something like: foo = bar; Is it a function call? I am learning to always put the () there to be explicit: foo = bar(); To improve code readability I think it may be better to remove this feature from the language (and later that may be used to simplify the object instantiation syntax). Bye, bearophile
Feb 06 2008
Robert Fraser wrote:I agree with you on that particular syntax. I think when it's a member of some sort, that syntax should be allowed, though (to allow a property syntax), but for free functions it's a bad idea.The argument for class properties applies equally well to global variables. -- E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Feb 06 2008
Matti Niemenmaa wrote:Robert Fraser wrote:Oops, forgot about those... alright, well I guess then people just need to be careful with this syntax.I agree with you on that particular syntax. I think when it's a member of some sort, that syntax should be allowed, though (to allow a property syntax), but for free functions it's a bad idea.The argument for class properties applies equally well to global variables.
Feb 06 2008
Robert Fraser wrote:Matti Niemenmaa wrote:I've actually used that when making bindings for a C library which has got some volatile globals. Just property wrappers with volatile statements in them. At least it made the examples easier to port. Whether this syntax is good or bad in general, I'm not sure.Robert Fraser wrote:Oops, forgot about those... alright, well I guess then people just need to be careful with this syntax.I agree with you on that particular syntax. I think when it's a member of some sort, that syntax should be allowed, though (to allow a property syntax), but for free functions it's a bad idea.The argument for class properties applies equally well to global variables.
Feb 06 2008
It may be useful for properties, but when you see something like: foo = bar; Is it a function call? I am learning to always put the () there to be explicit: foo = bar();It really gets odd when foo is a function as well: void foo(int i); int bar(); foo = bar; // same as foo(bar()); I think property syntax is nice, but should only be valid where it makes sense (or only where the user explicitly allowed it). Christian Kamm
Feb 06 2008
Christian Kamm wrote:It really gets odd when foo is a function as well: void foo(int i); int bar(); foo = bar; // same as foo(bar()); I think property syntax is nice, but should only be valid where it makes sense (or only where the user explicitly allowed it).Agree. If there were, say, an attribute `property', so that you can write: foo(double x) {...} property double distance() {return ...} foo(distance); // OK foo(distance()); // OK foo = distance; // error it'd be much safer. SnakE
Feb 06 2008
Sergey Gromov <snake.scaly gmail.com> wrote:foo(double x) {...} property double distance() {return ...} foo(distance); // OK foo(distance()); // OK foo = distance; // errorOr even forbid to use the `double()' syntax for properties, and forbid to overload properties with non-property functions. In other words: foo(distance()); // error, can't use call syntax for properties double distance(int precision) {...} // error, can't overload a property -- SnakE
Feb 06 2008
Sergey Gromov wrote:Sergey Gromov <snake.scaly gmail.com> wrote:property syntax. Maybe something like this would be a better solution? private double myDistance; public property distance { double __get { return myDistance; } void __set(double val) { myDistance= val; } double* __addressOf { return &myDistance; } } double x = distance; // x = distance.__get(); distance = 50.0; // distance.__set(50.0); double* p = &distance; // p = distance.__addressOf(); And maybe add more property-properties as needed. This would make them first-class, fully interchangeable with variables.foo(double x) {...} property double distance() {return ...} foo(distance); // OK foo(distance()); // OK foo = distance; // errorOr even forbid to use the `double()' syntax for properties, and forbid to overload properties with non-property functions. In other words: foo(distance()); // error, can't use call syntax for properties double distance(int precision) {...} // error, can't overload a property
Feb 06 2008
Robert Fraser:property syntax. Maybe something like this would be a better solution?If you take a look at my last post of notes (the 4th) you can see I suggested Bye, bearophile
Feb 06 2008
Robert Fraser <fraserofthenight gmail.com> wrote:property syntax. Maybe something like this would be a better solution? private double myDistance; public property distance { double __get { return myDistance; } void __set(double val) { myDistance= val; } double* __addressOf { return &myDistance; } } double x = distance; // x = distance.__get(); distance = 50.0; // distance.__set(50.0); double* p = &distance; // p = distance.__addressOf(); And maybe add more property-properties as needed. This would make them first-class, fully interchangeable with variables.Yes, this would be far more consistent of course. I've just tried to keep to the current syntax and semantics as close as possible. -- SnakE
Feb 06 2008
Sergey Gromov wrote:Are you sure this is to the better ? I'm not quite fond of D's freedom in syntax. It already allows to write an unreadable code like this: use(context) in (GL gl) {draw(gl);} auto GetEven = stackthread = (int delegate() read, void delegate(int) yield) {...}I just don't like "});". The less closing parens the better. :) Semantically, read it as "auto GetEven = stackthread = (int delegate() read, void delegate(int) yield) { ... };]". --downs
Feb 06 2008
Sergey Gromov wrote:Are you sure this is to the better ? I'm not quite fond of D's freedom in syntax. It already allows to write an unreadable code like this: use(context) in (GL gl) {draw(gl);}And when I actually asked for comments about that syntax, no one stated that it was unreadable ... thanks for the (mislocated) feedback. As for the exact form of that use() in .. statement, I made it so with the sole purpose of it being *readable*. It may be new to you; it usually makes people think that the construct is built into D, resulting in some confusion ("did I miss anything in the spec?"). Yet ultimately using the language's features to write code which looks built-in makes code easier to read. If my statement is false, then using AST macros in lisp makes the code less readable as well. -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Feb 07 2008
Tom S <h3r3tic remove.mat.uni.torun.pl> wrote:Sergey Gromov wrote:I don't know where or when you have asked for this. It's not my job to read through years of discussions, and I'm not obligated to read every single post even though I do monitor the group. Someone has cited this code in D.learn asking what it does. That's exactly what I mean.Are you sure this is to the better ? I'm not quite fond of D's freedom in syntax. It already allows to write an unreadable code like this: use(context) in (GL gl) {draw(gl);}And when I actually asked for comments about that syntax, no one stated that it was unreadable ... thanks for the (mislocated) feedback.As for the exact form of that use() in .. statement, I made it so with the sole purpose of it being *readable*. It may be new to you; it usually makes people think that the construct is built into D, resulting in some confusion ("did I miss anything in the spec?"). Yet ultimately using the language's features to write code which looks built-in makes code easier to read. If my statement is false, then using AST macros in lisp makes the code less readable as well.I'm not familiar with Lisp. Anyway, when I say 'readable,' I mean that I can look into an unfamiliar code written by other person and understand, in general, what's happening. This class is having this method called with these arguments. That template is instantiated with those types. Basically, it should be enough to read language specification to understand the code. In your case you're inventing a construct which doesn't quite fit into specs, which in turn causes confusion. -- SnakE
Feb 07 2008
Sergey Gromov wrote:I don't know where or when you have asked for this. It's not my job to read through years of discussions, and I'm not obligated to read every single post even though I do monitor the group. Someone has cited this code in D.learn asking what it does. That's exactly what I mean.Ah, fine then, I thought you saw me pasting a more complete example on IRC on #d :) Anyway, here it is, so maybe it makes some more sense this time: http://paste.dprogramming.com/dpn66vhk It's an example from an unreleased OpenGL wrapper. The ext/use(...) in {}; constructs actually play an important role in its functioning, restricting access to the resource to a controlled region, executing special code before and after it, and in the case of 'ext', allowing an extra parameter after a variadic one.I'm not familiar with Lisp. Anyway, when I say 'readable,' I mean that I can look into an unfamiliar code written by other person and understand, in general, what's happening. This class is having this method called with these arguments. That template is instantiated with those types. Basically, it should be enough to read language specification to understand the code. In your case you're inventing a construct which doesn't quite fit into specs, which in turn causes confusion.Doesn't fit into the specs? How so? It's not like I'm preprocessing D. I've talked with a few folks who have been coding in D for a while, and they immediately recognized the constructs. The func call, proxy object, opIn and the inline delegate. It's not a surprise that fancy D code may cause confusion in D.learn, since well, it's an NG for beginners... Let's take another example. For someone coming from Java, operator overloads might be unreadable code because when they see a + b, they can't know what's happening. But it's normal for D code. Someone coming from C would see any OO stuff unreadable. D is a relatively new language and there really isn't a common understanding of how 'readable' D code should look like. It's got its very own feel and syntax, to which programmers must get used and perhaps notice that some things can be implemented in a much different way than in their old favorite language. -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Feb 07 2008
Tom S <h3r3tic remove.mat.uni.torun.pl> wrote:Sergey Gromov wrote:OK so I'm new to D, too. It's a part of a problem. I have quite strong C/C++/Java background, and I do like the strictness of Java. But anyway. opIn has a distinct default semantics in the language. It's "check if," not an "apply to." The ability to overload is here to mimic the default semantics for non-ordinary types. It's a bad practice IMO to completely change operator semantics. That's exactly why a concatenation operator is added to D: to ensure that what you think is being done is actually what is done, at least conceptually. That's also the reason I didn't like the luabind library for C++. Here's a piece of C++ code: module(L) [ def("greet", &greet) ]; What it does, God knows. -- SnakEI'm not familiar with Lisp. Anyway, when I say 'readable,' I mean that I can look into an unfamiliar code written by other person and understand, in general, what's happening. This class is having this method called with these arguments. That template is instantiated with those types. Basically, it should be enough to read language specification to understand the code. In your case you're inventing a construct which doesn't quite fit into specs, which in turn causes confusion.Doesn't fit into the specs? How so? It's not like I'm preprocessing D. I've talked with a few folks who have been coding in D for a while, and they immediately recognized the constructs. The func call, proxy object, opIn and the inline delegate. It's not a surprise that fancy D code may cause confusion in D.learn, since well, it's an NG for beginners...
Feb 07 2008
Sergey Gromov wrote:opIn has a distinct default semantics in the language. It's "check if," not an "apply to." The ability to overload is here to mimic the default semantics for non-ordinary types. It's a bad practice IMO to completely change operator semantics.Well then, the whole C++ committee is following bad practice as well, by making << and >> work with streams. Following semantics is one thing - sure. It's crucial when you're making your own Map container to support it in exactly the same way as the built-in AAs do. But if you can make your code more natural to write by abusing the operators a little - opIn, operator<<, etc, then it's not a very bad practice IMHO. In fact, anyone defining opMul for their matrix class/struct is breaking semantics. The spec states that opMul is commutative.That's exactly why a concatenation operator is added to D: to ensure that what you think is being done is actually what is done, at least conceptually.Wrong. As far as I know, it was added because D was supposed to have array operations, so you could say [1, 2] + [10, 10] and have [11, 12], not the concatenation.That's also the reason I didn't like the luabind library for C++. Here's a piece of C++ code: module(L) [ def("greet", &greet) ]; What it does, God knows.It doesn't really matter. Would you actually know without looking at the implementation? It's easy to read, the language features used can be figured out rather easily. What matters is that it's really easy to use. It's actually a very nice example of a DSL (Domain Specific Language) within C++. Would you rather write 4 times this much, in order just to have it look like the rest of C++ code? Because then, there's the low level C API... -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Feb 07 2008
What can I say. I do not agree. C++ committee is not the best exemplar. Looking into implementation should be required to learn the details, not to understand what the hell is going on. Creating the DSLs should be a privilege of scripting languages, that's what they are for, after all. Tom S <h3r3tic remove.mat.uni.torun.pl> wrote:Sergey Gromov wrote:-- SnakEopIn has a distinct default semantics in the language. It's "check if," not an "apply to." The ability to overload is here to mimic the default semantics for non-ordinary types. It's a bad practice IMO to completely change operator semantics.Well then, the whole C++ committee is following bad practice as well, by making << and >> work with streams. Following semantics is one thing - sure. It's crucial when you're making your own Map container to support it in exactly the same way as the built-in AAs do. But if you can make your code more natural to write by abusing the operators a little - opIn, operator<<, etc, then it's not a very bad practice IMHO. In fact, anyone defining opMul for their matrix class/struct is breaking semantics. The spec states that opMul is commutative.That's exactly why a concatenation operator is added to D: to ensure that what you think is being done is actually what is done, at least conceptually.Wrong. As far as I know, it was added because D was supposed to have array operations, so you could say [1, 2] + [10, 10] and have [11, 12], not the concatenation.That's also the reason I didn't like the luabind library for C++. Here's a piece of C++ code: module(L) [ def("greet", &greet) ]; What it does, God knows.It doesn't really matter. Would you actually know without looking at the implementation? It's easy to read, the language features used can be figured out rather easily. What matters is that it's really easy to use. It's actually a very nice example of a DSL (Domain Specific Language) within C++. Would you rather write 4 times this much, in order just to have it look like the rest of C++ code? Because then, there's the low level C API...
Feb 07 2008
On Feb 8, 2008 3:20 AM, Sergey Gromov <snake.scaly gmail.com> wrote:What can I say. I do not agree. C++ committee is not the best exemplar. Looking into implementation should be required to learn the details, not to understand what the hell is going on. Creating the DSLs should be a privilege of scripting languages, that's what they are for, after all.How is this different from other code? You have to look in any implementation code to figure out what's going on internally, be it with syntax sugar or not. Anders
Feb 07 2008
Anders Bergh <anders1 gmail.com> wrote:On Feb 8, 2008 3:20 AM, Sergey Gromov <snake.scaly gmail.com> wrote:If there is a bug, and I know it's /not/ in the OpenGL sub-system, and I can tell that OpenGL sub-system from the rest of the code, then I don't need to look into it. On the other hand, if I can't recognize the code, I automatically consider it error prone due to its non-obvious nature. I just have to look into it, to make sure it works. -- SnakEWhat can I say. I do not agree. C++ committee is not the best exemplar. Looking into implementation should be required to learn the details, not to understand what the hell is going on. Creating the DSLs should be a privilege of scripting languages, that's what they are for, after all.How is this different from other code? You have to look in any implementation code to figure out what's going on internally, be it with syntax sugar or not.
Feb 08 2008
Sergey Gromov wrote:If there is a bug, and I know it's /not/ in the OpenGL sub-system, and I can tell that OpenGL sub-system from the rest of the code, then I don't need to look into it. On the other hand, if I can't recognize the code, I automatically consider it error prone due to its non-obvious nature. I just have to look into it, to make sure it works.Uhm.. you consider code error-prone because you can't parse it in your head? Wow. Then there's lots of error-prone code out there in other languages I don't know! They're all bad and error-prone languages!
Feb 08 2008
Alexander Panek <alexander.panek brainsware.org> wrote:Sergey Gromov wrote:Don't you see the difference between "it is" and "I consider" ? If I'm searching for a bug, and I don't understand some code, I *must* check it. -- SnakEIf there is a bug, and I know it's /not/ in the OpenGL sub-system, and I can tell that OpenGL sub-system from the rest of the code, then I don't need to look into it. On the other hand, if I can't recognize the code, I automatically consider it error prone due to its non-obvious nature. I just have to look into it, to make sure it works.Uhm.. you consider code error-prone because you can't parse it in your head? Wow. Then there's lots of error-prone code out there in other languages I don't know! They're all bad and error-prone languages!
Feb 08 2008
Sergey Gromov wrote:Alexander Panek <alexander.panek brainsware.org> wrote:Are there bugs in there?Sergey Gromov wrote:Don't you see the difference between "it is" and "I consider" ? If I'm searching for a bug, and I don't understand some code, I *must* check it.If there is a bug, and I know it's /not/ in the OpenGL sub-system, and I can tell that OpenGL sub-system from the rest of the code, then I don't need to look into it. On the other hand, if I can't recognize the code, I automatically consider it error prone due to its non-obvious nature. I just have to look into it, to make sure it works.Uhm.. you consider code error-prone because you can't parse it in your head? Wow. Then there's lots of error-prone code out there in other languages I don't know! They're all bad and error-prone languages!
Feb 08 2008
Sergey Gromov wrote:What can I say. I do not agree. C++ committee is not the best exemplar. Looking into implementation should be required to learn the details, not to understand what the hell is going on. Creating the DSLs should be a privilege of scripting languages, that's what they are for, after all.As long as you understand the language, you should understand more or less 'what the hell is going on'. Doesn't make much difference for comprehension, whether it's written using syntax sugar or not. Yet it may be more pleasant to read when it's *with* sugar. As for your argument with scripting languages? Do you suggest that the binding to Lua from C++ should be done... with a scripting language? That wouldn't make much sense. And yet, the folks have managed to create a very nice DSL within C++ that makes the code look really nice. Or should my GL wrapper *for D* be running through a scripting language? What can I say. I do not agree. Scripting languages have their uses, but when the 'main' language is powerful enough, you don't need them that much. -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Feb 07 2008
Tom S Wrote:Well then, the whole C++ committee is following bad practice as well, by making << and >> work with streams.Right, a committee too can take bad choices, that operator usage is very unnatural, and it will always be for a C-based language. Operator overloading is useful, but like with all the situations where you have more power, you need more control too (this will become very clear when D will have macros. They will require a very strong self-discipline from the programmer, otherwise they will lead to big problems, mostly at the level of *language community*, and not at the level of single program. I have explained this in my 4th post of notes). So you have to use them avoiding to change their original semantics too much. Otherwise code becomes a jungle that a different programmer can't read well. As far as I know Java outlaws operator overloading essentially to avoid that class of problems. Java success comes from it being good for the *community* of Java programmers, and not just for the single programmer. Making the language simple and regular allows everyone to understand code written by others, and modify it, share it, etc. It also allows firms to take young programmers and use them to manage legacy Java code, etc, it allows to *lot* of less good programmers to use the language, like most of the people that today are using Processing, a graphics processing language that is essentially Java with few libs and some added sugar. You can also read this section, it says right things: http://en.wikipedia.org/wiki/Operator_overloading#Criticisms Other languages don't outlaw it, like Python (despite giving less possibilities of op overload to help keep things more tidy). But you have to remember that generally even if something isn't outlawed it doesn't mean it's better for everyone to use it all the time. You don't have to use op overload *too much*. And you need some programming experience to know what "too much" means in a specific context. In this context program readability is more important that reducing the code to 2 lines instead of 4 without too much op overload. Note that DSL (Domain Specific Language) isn't something mostly for scripting languages, they come from Lisp (and Forth too, probably) that can be compiled into a normal executable. D with macros will be fit for that too. Bye, bearophile
Feb 08 2008
bearophile wrote:Tom S Wrote:But perhaps there was no way to make it look better?Well then, the whole C++ committee is following bad practice as well, by making << and >> work with streams.Right, a committee too can take bad choices, that operator usage is very unnatural, and it will always be for a C-based language.Operator overloading is useful, but like with all the situations where you have more power, you need more control too (this will become very clear when D will have macros. They will require a very strong self-discipline from the programmer, otherwise they will lead to big problems, mostly at the level of *language community*, and not at the level of single program. I have explained this in my 4th post of notes).So you have to use them avoiding to change their original semantics too much. Otherwise code becomes a jungle that a different programmer can't read well.You've also stated that the programmer doesn't have to understand what's going on inside a standard lib (as long as it reads well and is consistent across its span). The code of mine which spawned this discussion is to be used like a standard lib for interfacing with OpenGL. Same situation. And it doesn't abuse operator overloading 'too much'. It's just one specific construct.As far as I know Java outlaws operator overloading essentially to avoid that class of problems. Java success comes from it being good for the *community* of Java programmers, and not just for the single programmer. Making the language simple and regular allows everyone to understand code written by others, and modify it, share it, etc.Disclaimer: I don't like Java. // It also is a total PITA to write.It also allows firms to take young programmers and use them to manage legacy Java code, etc,// I'm grateful for that. Otherwise thedailywtf.com would lose half of its sources.it allows to *lot* of less good programmers to use the language, like most of the people that today are using Processing, a graphics processing language that is essentially Java with few libs and some added sugar.If Java was so great, why did Processing need the extra sugar? Similarly, I don't want to use something different from D to write my code because just I feel like having more sugar. D can provide it as well.You can also read this section, it says right things: http://en.wikipedia.org/wiki/Operator_overloading#CriticismsIt also highlights that there are two sides in the debate. And it doesn't seem like the discussion ever ends, so I'd rather leave this thread as is and not let it turn into a complete flame war ;)Note that DSL (Domain Specific Language) isn't something mostly for scripting languages, they come from Lisp (and Forth too, probably) that can be compiled into a normal executable. D with macros will be fit for that too.That was also my point -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Feb 08 2008
Tomasz Stachowiak:You've also stated that the programmer doesn't have to understand what's going on inside a standard lib (as long as it reads well and is consistent across its span).<I think all I have said was "I agree" :-) So I can explain a bit better. I like to understand what's inside the std lib, because I think that if you want to use a system well, you have to know something about the layer just below the one you are using (C if you use Python, assembly/CPU if you use C, the GC and the std Lib and the assembly/CPU if you use D, etc). I have found problems in using D (to built some collection data structures) because I have yet to understand how the heck the Phobos GC actually behaves. Some kinds of languages (and their communities) like Java think that having opaque objects is better. Other languages like Python think that's not always a good thing, and the usual coding style is different. I think both views of the situation have their merits and disadvantages, I like both styles, and I think they are fit for the languages they are used in, and the typical situations they are used in. If you want I can offer more details. Bye, bearophile
Feb 08 2008
Sergey Gromov wrote:I wonder why .sizeof is implemented as a property while typeof() and typeid() are functions. I can see no reasons for such inconsistency. It's not that obvious for typeof() because it yields a type instead of a value, but even then, why not ?Because expression.identifier always yields an expression, whereas typeof() always yields a type. It makes parsing easier and more consistent.
Feb 06 2008
Walter Bright wrote:Sergey Gromov wrote:typeid yeilds an expression...I wonder why .sizeof is implemented as a property while typeof() and typeid() are functions. I can see no reasons for such inconsistency. It's not that obvious for typeof() because it yields a type instead of a value, but even then, why not ?Because expression.identifier always yields an expression, whereas typeof() always yields a type. It makes parsing easier and more consistent.
Feb 06 2008
Robert Fraser wrote:Walter Bright wrote:The subject says typeid, the post says typeof ! typeid(type) looks for a type between the parentheses, and a type has a different grammar than an expression.Sergey Gromov wrote:typeid yeilds an expression...I wonder why .sizeof is implemented as a property while typeof() and typeid() are functions. I can see no reasons for such inconsistency. It's not that obvious for typeof() because it yields a type instead of a value, but even then, why not ?Because expression.identifier always yields an expression, whereas typeof() always yields a type. It makes parsing easier and more consistent.
Feb 06 2008
Walter Bright wrote:Robert Fraser wrote:real.nan?typeid yeilds an expression...The subject says typeid, the post says typeof ! typeid(type) looks for a type between the parentheses, and a type has a different grammar than an expression.
Feb 07 2008
Christopher Wright wrote:Walter Bright wrote:Yields an expression, not a type.Robert Fraser wrote:real.nan?typeid yeilds an expression...The subject says typeid, the post says typeof ! typeid(type) looks for a type between the parentheses, and a type has a different grammar than an expression.
Feb 07 2008
Walter Bright wrote:Christopher Wright wrote:typeid yields an expression, not a type.Walter Bright wrote:Yields an expression, not a type.Robert Fraser wrote:real.nan?typeid yeilds an expression...The subject says typeid, the post says typeof ! typeid(type) looks for a type between the parentheses, and a type has a different grammar than an expression.
Feb 08 2008
On Wed, 06 Feb 2008 18:51:49 -0800, Walter Bright wrote:Sergey Gromov wrote:From a users perspective, my first thought is always that it should be used similar to a type alias in a struct/class. .typeof feels also more consistent with .length, .sizeof or .stringof. typeof() looks like a build-in compile time function, but the feeling to access the AST is definitely nicer. Thought, I don't know if typeof() is worth the gains on the parsing side.I wonder why .sizeof is implemented as a property while typeof() and typeid() are functions. I can see no reasons for such inconsistency. It's not that obvious for typeof() because it yields a type instead of a value, but even then, why not ?Because expression.identifier always yields an expression, whereas typeof() always yields a type. It makes parsing easier and more consistent.
Feb 06 2008