Re: IDE with renaming possibility
I use Emacs and replace regexp. Hi, I'm looking for a solution that replaces just in the scope. A regexp replace would change all occurrences :( Also, if you have a function that is implemented in a module and you call it in another file, it should be renamed everywhere. Laszlo
Re: My new least favorite one-liner...
On Sun, 06 Nov 2011 04:39:28 -, Jude Young 10equa...@gmail.com wrote:
Nice. Exactly what I was looking for.
I knew I was missing something tiny.
Now I just need to figure out why that works and I can say I've learned
something!
Thanks guys,
Jude
On Sat, Nov 5, 2011 at 5:38 AM, bearophile bearophileh...@lycos.com
wrote:
Jude Young:
icon = *(toStringz(text(num)));
icon is a char, num is an integer.
Are you trying to convert a single-digit number?
import std.stdio;
void main() {
int x = 5; // in [0 .. 10]
char c = cast(char)(x + '0');
writeln(c);
}
You've also got std.ascii.digits which is 0123456789 and
std.string.digits which is an alias of it, so you can say:
import std.ascii; (or std.string)
int x = 5;
char c = std.ascii.digits[x];
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: odd use of preprocessor
On 06-11-2011 21:36, Ellery Newcomer wrote:
On 11/06/2011 01:50 PM, Alex Rønne Petersen wrote:
On 06-11-2011 20:43, Ellery Newcomer wrote:
poking about in elfutils headers, I've come across the following idiom
several times
/* Error values. */
enum
{
DW_TAG_invalid = 0
#define DW_TAG_invalid DW_TAG_invalid
};
anyone know if anything strange is going on here that would prevent
trivial conversion to d?
The only thing I can think of is fully-qualified enums. The #define
ensures that you _don't_ have to fully qualify DW_TAG_invalid. But why
they would do this (considering C doesn't have this enum feature), I
don't know.
- Alex
nor c++, right?
Even C++0x requires you to use 'enum class' for this effect. I assume
this is to cope with some random compiler's craziness. But I have no
idea, really.
- Alex
Re: Is this actually valid code?
class Foo
{
@property void test(int) {}
@property int test() { return 1; }
}
class Bar : Foo
{
alias super.test test;
override @property void test(int) {}
void bartest() { auto x = test; }
}
And it actually works! Is this a documented feature?
http://d-programming-language.org/hijack.html
Re: Is this actually valid code?
On Sun, 06 Nov 2011 23:10:57 -0500, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
I've had a simple problem where I've only wanted to override a setter
from a base class:
class Foo
{
@property void test(int) {}
@property int test() { return 1; }
}
class Bar : Foo
{
override @property void test(int) {}
void bartest() { auto x = test; } // NG
}
test.d(19): Error: function test.Bar.test (int _param_0) is not
callable using argument types ()
So I thought I'd be clever:
class Foo
{
@property void test(int) {}
@property int test() { return 1; }
}
class Bar : Foo
{
alias super.test test;
override @property void test(int) {}
void bartest() { auto x = test; }
}
And it actually works! Is this a documented feature?
http://www.d-programming-language.org/function.html#function-inheritance
Look at the third example/description.
-Steve
Re: My new least favorite one-liner...
Regan Heath wrote: You've also got std.ascii.digits which is 0123456789 and std.string.digits which is an alias of it, so you can say: import std.ascii; (or std.string) int x = 5; char c = std.ascii.digits[x]; I used similar solution to bearophile's before. I must admit i did not know about std.ascii.digits[], thanks for the info Regan.
Re: Is this actually valid code?
Cool stuff, thanks guys. This thing kicks some serious C++ ass. ^^
Re: Is this actually valid code?
Cool stuff, thanks guys. This thing kicks some serious C++ ass. ^^ How? You can use using in C++ to do the same.
Re: Is this actually valid code?
On 11/7/11, Trass3r u...@known.com wrote: Cool stuff, thanks guys. This thing kicks some serious C++ ass. ^^ How? You can use using in C++ to do the same. My bad. I was a bit over-excited there. :p
Re: Expected or Bug? struct range unmodified after foreach
On 11/07/2011 12:26 AM, Jesse Phillips wrote:
I'm sure if this was changed there would be other interesting behavior,
such as arrays being consumed. And suggestions other than
for(S s; !s.empty, s.popFront())...
Example:
void main() {
S s;
foreach(i; s) {
assert(i == s.popCount); // Fail
}
assert(s.popCount == 10); // Fail
}
struct S {
size_t popCount;
auto empty() {
if(popCount 9)
return true;
return false;
}
auto front() { return popCount; }
auto popFront() {
popCount++;
}
}
Expected, s has value semantics.
for(S _s=s; !_s.empty(); _s.popFront()){
auto i = _s.front();
// assert(i == s.popCount()); // expected to fail.
}
extends and implements
Hello.
I know D isn't Java, but one trivial thing I liked about Java is
the introduction of 'extends' and 'implements' as keywords as ways
to clarify the class relationships when defining a class. You
know:
class Subclass extends SuperClass implements AnInterface {
...
}
Will they ever add this in to D? If not, why not?
thanks.
Re: extends and implements
On Mon, 07 Nov 2011 13:22:07 -0500, %u n...@devnull.com wrote:
Hello.
I know D isn't Java, but one trivial thing I liked about Java is
the introduction of 'extends' and 'implements' as keywords as ways
to clarify the class relationships when defining a class. You
know:
class Subclass extends SuperClass implements AnInterface {
...
}
Will they ever add this in to D?
No.
If not, why not?
In order for such a humongously code-breaking change to occur, there would
have to be dire reasons why this was necessary. Because you liked Java is
not a qualifying reason.
-Steve
Re: extends and implements
If you need some kind of textual information on whether its a class or
an interface, you can name your interfaces with an I.
interface IShape
{
}
abstract class Drawable
{
}
class Rectangle : IShape, Drawable {}
It's pretty common in other languages, I've seen it used in D as well.
Re: extends and implements
On 07-11-2011 19:22, %u wrote:
Hello.
I know D isn't Java, but one trivial thing I liked about Java is
the introduction of 'extends' and 'implements' as keywords as ways
to clarify the class relationships when defining a class. You
know:
class Subclass extends SuperClass implements AnInterface {
...
}
Will they ever add this in to D? If not, why not?
thanks.
Programming isn't natural language (or some variation thereof). I don't
see what's wrong with using ':' for this. It's clear what it does, and
not ambiguous in any way.
- Alex
Re: extends and implements
You can do this and/or use the convention of extends first, implements
second:
class Rectangle : Drawable, IShape, IOtherInterface {}
If you're really concerned about clarity, use comments:
class Rectangle : /* extends */ Drawable,
/* implements */ IShape
{
}
Andrej Mitrovic wrote:
If you need some kind of textual information on whether its a class or
an interface, you can name your interfaces with an I.
interface IShape
{
}
abstract class Drawable
{
}
class Rectangle : IShape, Drawable {}
It's pretty common in other languages, I've seen it used in D as well.
Re: extends and implements
You can do this and/or use the convention of extends first, implements
second:
class Rectangle : Drawable, IShape, IOtherInterface {}
It's not a convention, the spec demands that.
http://d-programming-language.org/class.html
If you're really concerned about clarity, use comments:
class Rectangle : /* extends */ Drawable,
/* implements */ IShape
{
}
Good point.
Re: Stop TypeTuple as template parameter from expanding
On 11/05/2011 03:23 PM, bearophile wrote: Tobias Pankrath: I do like it, just it would be nice to have an alternative in phobos, iff there is no other way I am not aware of. Type tuples (that are allowed to contain more than just types) aren't Phobos constructs, they are built-in in the language. -- Christophe: You could always make them non-flattening by default, and create an operator to flatten them. Yeah, but Type tuples are tricky built-in things, with a semantics quite constrained, so I don't know if this is possible. -- Dejan Lekic: bearophile - I believe it is a matter of taste. When you design a language most decisions are based on taste, because there are very few scientific studies on this topic (despite the importance of this field). A computer language is an interface between a specific implementation of not-tar-pit Turing machine and a partially sentient ape with a brain full of evolutionary design bugs. The design of programming languages touches low-determinism topics like ergonomy, usability, cognitive psycology, primate instincts, human cognitive skills and capabilities, human senses limits and capabilities, human mind design bugs, etc. So probably designing computer languages can't fully become a field of engineering. On the other hand trained taste is not arbitrary, and there are negative examples from past languages to learn from. On the third hand, most of the ideas I show in the D newsgroups turn up being wrong :-) I actually prefer it the D way because (S, T...) is a TypeTuple as well. (MyList, A, B, C) expands to (A, B, C, A, B, C) so it makes sense that Test prints what it prints. It is all natural to me... It should be like that in my humble opinion. One of the most hated feature of Perl language is the Auto-flattening of its arrays: http://en.wikibooks.org/wiki/Perl_Programming/Array_Variables#Array_Assignment This anti-feature makes it harder to create nest arrays and in general to create nested structures (that are so natural to do in Python. There are ways to nest arrays in Perl too). As Christophe notes, it's much simpler to have Python-like lists that nest and then write and use a short recursuive flatten function in the (uncommon) cases it's needed, than trying (and failing) to invent ways to produce some nesting when your data structure auto-flattens :-( If TypeTuples nest, this too keeps being one TypeTuple: TypeTupleX!(TypeTupleX!(A, B, C), A, B, C) Bye, bearophile It is _easy_ to put a TypeTuple into a nesting box. (but I have never needed to.) Usually you don't want the TypeTuples to nest, so why should that be the default?
Re: extends and implements
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article On Mon, 07 Nov 2011 13:22:07 -0500, %u n...@devnull.com wrote: In order for such a humongously code-breaking change to occur, there would have to be dire reasons why this was necessary. Because you liked Java is not a qualifying reason. -Steve Hey man, Sorry if I annoyed you. No need to feel insulted. I get it: the *real* reason is that it will break alot of code. I'm just asking, it's not a big deal. I find that it helps readability. But as others have stated, you list the the extended class first and that's good enough! thanks.
Re: extends and implements
On Mon, 07 Nov 2011 14:07:56 -0500, %u n...@.com wrote: == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article On Mon, 07 Nov 2011 13:22:07 -0500, %u n...@devnull.com wrote: In order for such a humongously code-breaking change to occur, there would have to be dire reasons why this was necessary. Because you liked Java is not a qualifying reason. -Steve Hey man, Sorry if I annoyed you. No need to feel insulted. I get it: the *real* reason is that it will break alot of code. I'm just asking, it's not a big deal. I find that it helps readability. But as others have stated, you list the the extended class first and that's good enough! The Internet is not always conducive to the emotional interpretation of words. Sorry if I sounded annoyed/insulted. I simply was identifying that you asked for a change that would break almost all code, and your reason was because you liked it. I'm not annoyed, but I wanted you to understand what you were asking for and what appears to be your reason. We would need more -- a lot more. That being said, even if there was a really good reason (maybe there is, I don't know), the bar for changing something so common in the syntax has to be set very very high. It may be something we can't change even if it's for a good reason. -Steve
Re: extends and implements
Andrej Mitrovic wrote:
class Rectangle : IShape, Drawable {}
It's pretty common in other languages, I've seen it used in D as well.
I used the same naming convention for interfaces until I saw this
presentation: http://www.infoq.com/presentations/It-Is-Possible-to-Do-OOP-
in-Java (jump to 0:42 if you do not want to see this brilliant
presentation).
In short there is an interface RecentlyUsedList, and Kevin recommends that
good name for implementation is something like ArrayBasedRecentlyUsedList.
And he is also against IRecentlyUsedList names... I actually agree with what
he suggests, and stopped using INames for interfaces. :)
PS. the presentation is not Java advocacy, it contains lots of Java
criticism...
Any othe options for inserting into associative array?
Came across this when trying to get Juno to work. Is there a good workaround
for it?
http://d.puremagic.com/issues/show_bug.cgi?id=6906
test.d(6): Error: function test.S.opAssign (int i) is not callable using
argument types (S)
void main() {
S[string] ss;
S s;
ss[hello] = s;
}
struct S {
void opAssign(int i) {
}
}
Re: Any othe options for inserting into associative array?
On 07/11/2011 20:27, Jesse Phillips wrote:
Came across this when trying to get Juno to work. Is there a good workaround
for it?
http://d.puremagic.com/issues/show_bug.cgi?id=6906
test.d(6): Error: function test.S.opAssign (int i) is not callable using
argument types (S)
void main() {
S[string] ss;
S s;
ss[hello] = s;
}
struct S {
void opAssign(int i) {
}
}
I have a recollection that i replaced an opAssign with a custom assign
function when getting Juno to build with D2 a while ago because of
something like this (was in the MethodProxy struct in com.client). That
did hit a different DMD bug at the time as well though.
Not ideal, but it got it working at least.
Implicit case fallthrough warns only when a statement is in place
import std.stdio;
void main()
{
int y;
switch (y)
{
case 0:
{
// no warning here on fallthrough
}
case 1:
{
goto case 2;
}
case 2:
{
writeln(2);
break;
}
default:
}
}
This won't trigger any warnings when compiled via -w and -wi, and I
think this could be improved.
DMD will trigger this warning only if you have a statement inside of
'case 0'. There could be a situation where you forgot to put a break
statement (inside case 0), and you end up in a different case handler
due to the fallthrough to the next case label which has a 'goto'
statement just like above.
From what I recall of the fallthrough topic, we can either put the
labels together if we really want fallthrough:
case 0:
case 1:
{
//...
}
or use goto case, or an explicit goto:
case 0:
{
goto case; // or goto case 1;
}
case 1:
{
//...
}
IOW, if you have a case defined with braces there should be a warning
on implicit fallthrough.
I did have a bug pop up because I was relying on this new fallthrough
warning system, but it failed to warn me because I didn't have a
statement in one of my cases (I forgot to put a break).
Re: Implicit case fallthrough warns only when a statement is in place
On Monday, November 07, 2011 15:38 Andrej Mitrovic wrote:
import std.stdio;
void main()
{
int y;
switch (y)
{
case 0:
{
// no warning here on fallthrough
}
case 1:
{
goto case 2;
}
case 2:
{
writeln(2);
break;
}
default:
}
}
This won't trigger any warnings when compiled via -w and -wi, and I
think this could be improved.
DMD will trigger this warning only if you have a statement inside of
'case 0'. There could be a situation where you forgot to put a break
statement (inside case 0), and you end up in a different case handler
due to the fallthrough to the next case label which has a 'goto'
statement just like above.
From what I recall of the fallthrough topic, we can either put the
labels together if we really want fallthrough:
case 0:
case 1:
{
//...
}
or use goto case, or an explicit goto:
case 0:
{
goto case; // or goto case 1;
}
case 1:
{
//...
}
IOW, if you have a case defined with braces there should be a warning
on implicit fallthrough.
I did have a bug pop up because I was relying on this new fallthrough
warning system, but it failed to warn me because I didn't have a
statement in one of my cases (I forgot to put a break).
I expect that it's simpler for the compiler to not worry about the braces,
since it can just look at the AST without worrying about the tokens. I don't
know if Walter would consider it worth changing it for this particular case or
not. Just open up an enhancement request.
- Jonathan M Davis
Re: Implicit case fallthrough warns only when a statement is in place
Andrej Mitrovic: I did have a bug pop up because I was relying on this new fallthrough warning system, but it failed to warn me because I didn't have a statement in one of my cases (I forgot to put a break). -.- This is the consequence of special cases piled on special cases, in the D design. (I agree with Jonathan here). Bye, bearophile
Re: Any othe options for inserting into associative array?
On Mon, 07 Nov 2011 20:59:05 +, Richard Webb wrote: I have a recollection that i replaced an opAssign with a custom assign function when getting Juno to build with D2 a while ago because of something like this (was in the MethodProxy struct in com.client). That did hit a different DMD bug at the time as well though. Not ideal, but it got it working at least. Saw your post about the same question when digging through the Juno forms. Yep it is the exact same one. Hopefully GitHub facilitates more interest in contributing. It definitely makes it easier.
Re: extends and implements
On Mon, 07 Nov 2011 18:22:07 +, %u wrote:
Hello.
I know D isn't Java, but one trivial thing I liked about Java is the
introduction of 'extends' and 'implements' as keywords as ways to
clarify the class relationships when defining a class. You know:
class Subclass extends SuperClass implements AnInterface {
...
}
Will they ever add this in to D? If not, why not?
thanks.
There are only two instances I like know if something is an interface or
class.
The first is when I am defining it, for some reason I want to tell the
whole world, Hey I'm building an interface here so be sure to include
these. Which really isn't important.
The second is when I want to find its definition. Hmmm, should I be
greping for /class Window/, /interface Window/, or /struct Window/
Otherwise the distinction has been pointless.
Re: Expected or Bug? struct range unmodified after foreach
On Mon, 07 Nov 2011 18:52:19 +0100, Timon Gehr wrote:
Expected, s has value semantics.
for(S _s=s; !_s.empty(); _s.popFront()){
auto i = _s.front();
// assert(i == s.popCount()); // expected to fail.
}
Yes thank you. I was just hoping to have access to _s inside the loop.
And yeah, it likely would break lots of code. Granted I kind of wish all
ranges would be consumed unless specifying save().
Re: extends and implements
On 2011-11-07 20:36, Dejan Lekic wrote:
Andrej Mitrovic wrote:
class Rectangle : IShape, Drawable {}
It's pretty common in other languages, I've seen it used in D as well.
I used the same naming convention for interfaces until I saw this
presentation: http://www.infoq.com/presentations/It-Is-Possible-to-Do-OOP-
in-Java (jump to 0:42 if you do not want to see this brilliant
presentation).
In short there is an interface RecentlyUsedList, and Kevin recommends that
good name for implementation is something like ArrayBasedRecentlyUsedList.
And he is also against IRecentlyUsedList names... I actually agree with what
he suggests, and stopped using INames for interfaces. :)
PS. the presentation is not Java advocacy, it contains lots of Java
criticism...
If the interfaces are the primary API, not implementation specific
classes, then the interfaces should not be have a ugly ma,e qualify them
with I or similar. If there is a need to separate the class and
interface names then choose the ugly name of the implementation classes.
--
/Jacob Carlborg
Re: extends and implements
On 2011-11-08 03:07, Jesse Phillips wrote:
On Mon, 07 Nov 2011 18:22:07 +, %u wrote:
Hello.
I know D isn't Java, but one trivial thing I liked about Java is the
introduction of 'extends' and 'implements' as keywords as ways to
clarify the class relationships when defining a class. You know:
class Subclass extends SuperClass implements AnInterface {
...
}
Will they ever add this in to D? If not, why not?
thanks.
There are only two instances I like know if something is an interface or
class.
The first is when I am defining it, for some reason I want to tell the
whole world, Hey I'm building an interface here so be sure to include
these. Which really isn't important.
The second is when I want to find its definition. Hmmm, should I be
greping for /class Window/, /interface Window/, or /struct Window/
Otherwise the distinction has been pointless.
This should be handled by an IDE/editor with go-to-definition.
--
/Jacob Carlborg
