## digitalmars.D - Phango

"Janice Caron" <caron800 googlemail.com> writes:
I've started to like Tango, now that I've got bits of it working with Phobos :-)

With a bit of kludging, I've persuaded all of the examples in the
"console" and "text" directories to build with Phobos using DMD 2.007.
Of the examples files, only "properties.d" needed to be tweaked
slightly - and that was just to replace "char[]" with "string".

I think I'll attack the "conduits" folder next.

Anyway, someone tell me - does Tango have containers? If so, are there
any examples of use in the "examples" folder of the Tango download? I
couldn't find any.

Nov 15 2007
"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Janice Caron" <caron800 googlemail.com> wrote in message
news:mailman.70.1195164582.2338.digitalmars-d puremagic.com...
I've started to like Tango, now that I've got bits of it working with
Phobos :-)

With a bit of kludging, I've persuaded all of the examples in the
"console" and "text" directories to build with Phobos using DMD 2.007.
Of the examples files, only "properties.d" needed to be tweaked
slightly - and that was just to replace "char[]" with "string".

I think I'll attack the "conduits" folder next.

Anyway, someone tell me - does Tango have containers? If so, are there
any examples of use in the "examples" folder of the Tango download? I
couldn't find any.

http://www.dsource.org/projects/tango/docs/current/ is useful indeed.  Yes,
there are containers, in tango.util.collection.

Nov 15 2007
Frank Benoit <keinfarbton googlemail.com> writes:
 I don't want docs, I want example source code. I want something I can
compile, with tests to prove it's all working. Is there not a
test-suite handy?

http://www.dsource.org/projects/tango/wiki/ChapterStorage

and all the snippets are here

examples/manual/chapterStorage.d

Nov 15 2007
"Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Janice Caron" wrote
I've started to like Tango, now that I've got bits of it working with
Phobos :-)

With a bit of kludging, I've persuaded all of the examples in the
"console" and "text" directories to build with Phobos using DMD 2.007.
Of the examples files, only "properties.d" needed to be tweaked
slightly - and that was just to replace "char[]" with "string".

Just an FYI, some of us are working on a D 2.x compatible version of Tango.

Basically the hard part is adding const.

It's not release-ready yet, but I'm hoping once Walter has fixed const, we
should be able to finish the port.

Of course, it does not use Phobos... But hopefully that problem will be
solved soon also.

-Steve

Nov 15 2007
Bill Baxter <dnewsgroup billbaxter.com> writes:
I thought we agreed that this should be called "Phandango".  :-)

--bb

Nov 16 2007
Sean Kelly <sean f4.ca> writes:
Janice Caron wrote:
On 11/16/07, Alexander Panek <alexander.panek brainsware.org> wrote:

Just curious: why don't you use Tango and the freestanding functions of
Phobos

Lot of reasons.

(1) If an engine ain't broke, don't fix it.

Not to plug the Tango engine, but it does actually fix a number of bugs
which are listed in the D bug tracker and have not been fixed in Phobos.

(2) I like D2.007, and I'll be switching to D2.008 the day it comes out.

(3) I hate Tango, stylisticly. I hate the mixed case module names, and
the mixed case global variable names (e.g. Stdout). I want everything
to look and feel like Phobos.

I'm not a huge fan of the mixed case global variable names either, but
it does help them stand out, which I think is the point.  The mixed case
module names help make multi-word names more readable and also help
distinguish from directories, which is an advantage in such a large
library.  The C module names have been left lowercase to match the
original C names and to provide a visual distinction between the API
layer and Tango.

(4) Walter has been doing this for seven years or whatever, and has
earned my greatest respect. Ripping out the innards of D scares the
shit out of me - and not only that, I see no reason why I should have
to.

For what it's worth, the Tango core is based on Ares, which began as a
project perhaps four years ago (I've lost track).  So the Tango runtime
isn't perhaps quite as new as it may seem.

This way, I get to use the latest cutting-edge version of D, I can
make all the module names lowercase (yes, that matters!), and though
things like Stdout(x).newline compile and run, I don't have to use
them - I'll be able to throw in nicer looking functions that do the
same thing.

This is what wrapper functions are for, in my opinion.  But then Tango
was created because of a dissatisfaction with Phobos, so I can't really
object to a dissatisfaction with Tango ;-)

Sean

Nov 16 2007
Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
Janice Caron wrote:
(3) I hate Tango, stylisticly. I hate the mixed case module names, and
the mixed case global variable names (e.g. Stdout). I want everything
to look and feel like Phobos.

I'm not a huge fan of the mixed case global variable names either, but
it does help them stand out, which I think is the point.

Mixed case package/module names are avoided because there needs to be a
1:1 correspondence between file names and package/module names, and not
all file systems are case sensitive (like FAT32 and NTFS, for a couple
widely used examples).

Nov 18 2007
Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:

Sean Kelly wrote:
Janice Caron wrote:
(3) I hate Tango, stylisticly. I hate the mixed case module names, and
the mixed case global variable names (e.g. Stdout). I want everything
to look and feel like Phobos.

I'm not a huge fan of the mixed case global variable names either, but
it does help them stand out, which I think is the point.

Mixed case package/module names are avoided because there needs to be a
1:1 correspondence between file names and package/module names, and not
all file systems are case sensitive (like FAT32 and NTFS, for a couple
widely used examples).

As I said elsewhere in the thread, other FS _are_ case sensitive, and thus
you need to be aware of which case you use in either case, rendering the
argument moot. Early on in D history, I encountered several cases of
modules being saved on Windows, then not working on Linux with their
intended module names due to this. And this can only happen if the Windows
programmer typed in a file name with upper case letters, even though the
module name was all lower case.

--
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Nov 18 2007
torhu <no spam.invalid> writes:
Lars Ivar Igesund wrote:
>> Mixed case package/module names are avoided because there needs to be a
1:1 correspondence between file names and package/module names, and not
all file systems are case sensitive (like FAT32 and NTFS, for a couple
widely used examples).

As I said elsewhere in the thread, other FS _are_ case sensitive, and thus
you need to be aware of which case you use in either case, rendering the
argument moot. Early on in D history, I encountered several cases of
modules being saved on Windows, then not working on Linux with their
intended module names due to this. And this can only happen if the Windows
programmer typed in a file name with upper case letters, even though the
module name was all lower case.

I believe Walter's point is that "all package and module names are lower
case" is a simple rule that will help us avoid this problem, given that
everyone does their best to adhere to the rule.  I don't know how much
it matters, since I've never run into the problem myself.  But I just
tried it, and it shouldn't be hard to track down the problem based on
the compiler's error messages.  Not a big deal either way, it seems.

Nov 18 2007
Lars Ivar Igesund <larsivar igesund.net> writes:
torhu wrote:

Lars Ivar Igesund wrote:
>> Mixed case package/module names are avoided because there needs to be
>> a
1:1 correspondence between file names and package/module names, and not
all file systems are case sensitive (like FAT32 and NTFS, for a couple
widely used examples).

As I said elsewhere in the thread, other FS _are_ case sensitive, and
thus you need to be aware of which case you use in either case, rendering
the argument moot. Early on in D history, I encountered several cases of
modules being saved on Windows, then not working on Linux with their
intended module names due to this. And this can only happen if the
Windows programmer typed in a file name with upper case letters, even
though the module name was all lower case.

I believe Walter's point is that "all package and module names are lower
case" is a simple rule that will help us avoid this problem, given that
everyone does their best to adhere to the rule.  I don't know how much
it matters, since I've never run into the problem myself.  But I just
tried it, and it shouldn't be hard to track down the problem based on
the compiler's error messages.  Not a big deal either way, it seems.

Yes, I see his point. My point is that there is no difference from having
that as a rule, and CamelCased module names as a rule :) In both cases you
need to adhere to it.

--
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Nov 18 2007
Bill Baxter <dnewsgroup billbaxter.com> writes:
torhu wrote:
Lars Ivar Igesund wrote:
>> Mixed case package/module names are avoided because there needs to be a
1:1 correspondence between file names and package/module names, and not
all file systems are case sensitive (like FAT32 and NTFS, for a couple
widely used examples).

As I said elsewhere in the thread, other FS _are_ case sensitive, and
thus
you need to be aware of which case you use in either case, rendering the
argument moot. Early on in D history, I encountered several cases of
modules being saved on Windows, then not working on Linux with their
intended module names due to this. And this can only happen if the
Windows
programmer typed in a file name with upper case letters, even though the
module name was all lower case.

I believe Walter's point is that "all package and module names are lower
case" is a simple rule that will help us avoid this problem, given that
everyone does their best to adhere to the rule.  I don't know how much
it matters, since I've never run into the problem myself.  But I just
tried it, and it shouldn't be hard to track down the problem based on
the compiler's error messages.  Not a big deal either way, it seems.

There is another issue.  Often a module has basically only one main
class in it.  If the main class is called Foo, and that's all that's in
the module, some version of "Foo" is the logical name for the package
too.  But then if you use fully qualified names you end up with
Package.Foo.Foo when referring to the class in the module, which just
look *so* silly that it's easy to forget the second Foo.  But
package.foo.Foo looks more reasonable, since it's clear the second to
last "foo" is not a class name.

--bb

Nov 18 2007
Lars Ivar Igesund <larsivar igesund.net> writes:
Bill Baxter wrote:

torhu wrote:
Lars Ivar Igesund wrote:
>> Mixed case package/module names are avoided because there needs to be
>> a
1:1 correspondence between file names and package/module names, and not
all file systems are case sensitive (like FAT32 and NTFS, for a couple
widely used examples).

As I said elsewhere in the thread, other FS _are_ case sensitive, and
thus
you need to be aware of which case you use in either case, rendering the
argument moot. Early on in D history, I encountered several cases of
modules being saved on Windows, then not working on Linux with their
intended module names due to this. And this can only happen if the
Windows
programmer typed in a file name with upper case letters, even though the
module name was all lower case.

I believe Walter's point is that "all package and module names are lower
case" is a simple rule that will help us avoid this problem, given that
everyone does their best to adhere to the rule.  I don't know how much
it matters, since I've never run into the problem myself.  But I just
tried it, and it shouldn't be hard to track down the problem based on
the compiler's error messages.  Not a big deal either way, it seems.

There is another issue.  Often a module has basically only one main
class in it.  If the main class is called Foo, and that's all that's in
the module, some version of "Foo" is the logical name for the package
too.  But then if you use fully qualified names you end up with
Package.Foo.Foo when referring to the class in the module, which just
look *so* silly that it's easy to forget the second Foo.  But
package.foo.Foo looks more reasonable, since it's clear the second to
last "foo" is not a class name.

--bb

Using fully qualified class names are very seldom necessary in D, I find
using renaming imports are much more useful. I'd like to turn your argument
the other way round: If you do

import package.Foo;

then it make a lot of sense that you can just use your class Foo. I
understand that this may have been uncommon for those coming from C, but I
know of several C++ libraries (Object oriented) using header files with
capitalized names, Qt and Coin3D (Open Inventor) comes to mind. Qt wasn't
always this way, but changed with version 4. OI I think always did this,
and it is 15+ years old. Indeed, its top level package is "Inventor"!
FWIW, I think SGI and TrollTech is two of very few companies that have
created truly good library API's in C++.

I could of course also pull in Java and C# as examples, but those are
weirdly enough disregarded in this debate.

--
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Nov 18 2007
Bill Baxter <dnewsgroup billbaxter.com> writes:
Lars Ivar Igesund wrote:
Bill Baxter wrote:

torhu wrote:
Lars Ivar Igesund wrote:
>> Mixed case package/module names are avoided because there needs to be
>> a
1:1 correspondence between file names and package/module names, and not
all file systems are case sensitive (like FAT32 and NTFS, for a couple
widely used examples).

thus
you need to be aware of which case you use in either case, rendering the
argument moot. Early on in D history, I encountered several cases of
modules being saved on Windows, then not working on Linux with their
intended module names due to this. And this can only happen if the
Windows
programmer typed in a file name with upper case letters, even though the
module name was all lower case.

case" is a simple rule that will help us avoid this problem, given that
everyone does their best to adhere to the rule.  I don't know how much
it matters, since I've never run into the problem myself.  But I just
tried it, and it shouldn't be hard to track down the problem based on
the compiler's error messages.  Not a big deal either way, it seems.

class in it.  If the main class is called Foo, and that's all that's in
the module, some version of "Foo" is the logical name for the package
too.  But then if you use fully qualified names you end up with
Package.Foo.Foo when referring to the class in the module, which just
look *so* silly that it's easy to forget the second Foo.  But
package.foo.Foo looks more reasonable, since it's clear the second to
last "foo" is not a class name.

--bb

Using fully qualified class names are very seldom necessary in D, I find
using renaming imports are much more useful.

Ok, but then the most obvious name for the renamed import is the last
component of the dot-separated module name:
import Foo = Package.Name.Too.Long.Foo;
...
Foo.Foo

Of course you could rename the module lower-case 'foo', but you could
also just have named it in lowercase from the beginning.  Or you could
come up with some other convention.

But anyway, I agree that in Tango the package names are so long that
static import is impractical.  But for other libraries that's not the
case, and I think what a lot of people are after here is a convention
that's universally applicable.  I use static import all the time in my
code because Phobos' flatter naming works well with that, and my own
code also is usually only 1 or 2 levels deep.  But I also use renamed
and selective imports too, depending how much stuff I plan to use from
the module.
[As an aside I really wish I could do renamed and selective importing on
one line, like import mod=some.long.module : Foo, Bar; ]

Saying "don't use static import" isn't a very strong argument for the
Tango naming convention in my opinion.

I'd like to turn your argument
the other way round: If you do

import package.Foo;

then it make a lot of sense that you can just use your class Foo.

If that were the only way to do imports in D, then that would make a lot
of sense.  But we also have static, renamed, and selective imports and
their use should be encouraged.  They help keep the top-level namespace
clean, and help make code more readable by specifying explicitly where
symbols are coming from.

I
understand that this may have been uncommon for those coming from C, but I
know of several C++ libraries (Object oriented) using header files with
capitalized names, Qt and Coin3D (Open Inventor) comes to mind. Qt wasn't
always this way, but changed with version 4. OI I think always did this,
and it is 15+ years old. Indeed, its top level package is "Inventor"!
FWIW, I think SGI and TrollTech is two of very few companies that have
created truly good library API's in C++.

The comparison with C++ is not valid because in C++ namespaces and file
names are decoupled.  So in C++ something like
#include<Package/SubPackage/ClassName.h>  will generally put the
ClassName into the Package::SubPackage namespace.  Or sometimes just the
Package namespace.  I've never seen anyone create a
Package::SubPackage::ClassName namespace to enclose a class called
ClassName.  But in D you don't have a choice.  The full path always
becomes part of the namespace.

I could of course also pull in Java and C# as examples, but those are
weirdly enough disregarded in this debate.

I don't remember enough about how Java imports worked to comment, and
I've never touched C#.

--bb

Nov 18 2007
Lars Ivar Igesund <larsivar igesund.net> writes:
Bill Baxter wrote:

Lars Ivar Igesund wrote:

Using fully qualified class names are very seldom necessary in D, I find
using renaming imports are much more useful.

Ok, but then the most obvious name for the renamed import is the last
component of the dot-separated module name:
import Foo = Package.Name.Too.Long.Foo;
...
Foo.Foo

Of course you could rename the module lower-case 'foo', but you could
also just have named it in lowercase from the beginning.  Or you could
come up with some other convention.

But anyway, I agree that in Tango the package names are so long that
static import is impractical.  But for other libraries that's not the
case, and I think what a lot of people are after here is a convention
that's universally applicable.  I use static import all the time in my
code because Phobos' flatter naming works well with that, and my own
code also is usually only 1 or 2 levels deep.  But I also use renamed
and selective imports too, depending how much stuff I plan to use from
the module.
[As an aside I really wish I could do renamed and selective importing on
one line, like import mod=some.long.module : Foo, Bar; ]

I think it does? At least I think the spec allows it.

Saying "don't use static import" isn't a very strong argument for the
Tango naming convention in my opinion.

Never liked static imports :P The static keyword is probably part of that :)

I'd like to turn your argument
the other way round: If you do

import package.Foo;

then it make a lot of sense that you can just use your class Foo.

If that were the only way to do imports in D, then that would make a lot
of sense.  But we also have static, renamed, and selective imports and
their use should be encouraged.  They help keep the top-level namespace
clean, and help make code more readable by specifying explicitly where
symbols are coming from.

I
understand that this may have been uncommon for those coming from C, but
I know of several C++ libraries (Object oriented) using header files with
capitalized names, Qt and Coin3D (Open Inventor) comes to mind. Qt wasn't
always this way, but changed with version 4. OI I think always did this,
and it is 15+ years old. Indeed, its top level package is "Inventor"!
FWIW, I think SGI and TrollTech is two of very few companies that have
created truly good library API's in C++.

The comparison with C++ is not valid because in C++ namespaces and file
names are decoupled.  So in C++ something like
#include<Package/SubPackage/ClassName.h>  will generally put the
ClassName into the Package::SubPackage namespace.  Or sometimes just the
Package namespace.  I've never seen anyone create a
Package::SubPackage::ClassName namespace to enclose a class called
ClassName.  But in D you don't have a choice.  The full path always
becomes part of the namespace.

I could of course also pull in Java and C# as examples, but those are
weirdly enough disregarded in this debate.

I don't remember enough about how Java imports worked to comment, and
I've never touched C#.

I'll withdraw C# from the discussion, as I don't know all aspects well
enough. Java however requires module names to equal class names, whether
they are lowercased or CamelCased. I may agree that such comparisons
possibly aren't entirely applicable though, considering modules in D are
much more important than in those languages. They are encapsulated entities
themselves after all. Which, if used as such, would imply that casing
should be the same as for classes and structs.

I'll accept this match to end with a remis though, so I can stop posting
about this :)

--
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Nov 18 2007
Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
It is interesting to see how such a trivial thing as the capitalization
of module names can lead to a much more involved discussion than any of
Tango's technical merits ever have (possibly with one exception). It is
somewhat like making a choice between two equipment manufacturers from
the colors they use on the buttons. But form and style seems to be of
undervalued importance, and maybe there is more to this issue than it
appears. Either way, I cannot refrain from writing something about it
too. :)

Lars Ivar Igesund wrote:

Using fully qualified class names are very seldom necessary in D, I find
using renaming imports are much more useful. I'd like to turn your argument
the other way round: If you do

import package.Foo;

then it make a lot of sense that you can just use your class Foo.

What says that the module package.Foo contains a class named Foo? Most
of my own modules contain no classes at all, and many that do contain
more than one class. I know that (with different qualifiers), that is
true for Tango as well.

I wouldn't encourage module renaming, at least not without guidelines
for how things should be renamed. Lots of people making up their own
custom abbreviations for the same long module names can't lead to
something good.

I am personally quite fond of using FQN (fully qualified names) in
certain situations, but names such as

tango.util.collection.iterator.InterleavingIterator.InterleavingIterator

make that a tad inconvenient. :)

Three design choices in Tango seem to be:

* deep rather than shallow package hierarchy
* descriptive rather than abbreviated package names
* highly fragmented modules

In some ways, I tend to feel those three points are misdirected, or at
least taken a bit too far.

What are the reasons for dividing things into modules? First and
foremost, functionally independent parts should be separated so that one
can be replaced or used independent of the others. Secondly, there are
some issues with compile times and object file sizes, and the third
reason is convenience for the implementors. The reasons mentioned are in
descending order of importance. A library should always be designed for
its users, rather than for its implementers.

We humans, psychologically, tend not to be very hierarchical in our
categorization of the world. There is a basic level of categorization
that is the one most readily named and first learned (bird, cat, car).
The function of a categorization should be to provide the maximum amount
of information with the least amount of cognitive effort. The more fine
grained a categorization is, the more cognitive effort is needed. The
conclusion is that it would be cognitively advantageous to only separate
library entities into different modules if there is a relevant reason to
do so (for the purposes at hand).

I believe shallow hierarchies generally are better than deep, and also
that there should be a functional rather than logical separation between
packages.

So, instead of:

tango.util.collection.iterator.InterleavingIterator

couldn't there just be:

tango.collection.iterators

or perhaps even:

tango.collection

An interesting parallel is the taxonomy of plants and animals from the
18th century. The Linnaean taxonomy is a highly hierarchical
classification, where for instance the common snowdrop is classified as:

Plantae.Magnoliophyta.Liliopsida.Asparagales.Amaryllidaceae.
Galanthus.nivalis

But such names were considered too unwieldy to use in full, so a concise
binomial nomenclature was used as a supplement. The same snowdrop as
above in binomials is just:

Galanthus.nivalis

Regarding capitalized module names: As far as I see it, there are
entities (functions, classes, etc) and modules (std.string,
tango.text.convert.Format). I don't really see the point of making a
distinction between modules and packages, and therefore can't really see
a point in capitalizing the last part of the module name only. But on
the other hand, there is a precedent in the binomials above -- only the
other way around. :)

I could of course also pull in Java and C# as examples, but those are
weirdly enough disregarded in this debate.

Not so weird for Java at least (I don't know C# well enough to comment).
Java (more or less) forces file names to be identical to the sole public
class in them. There are no modules in java, just classes, and since
classes are capitalized, so are the file names.

To end, I think it speaks very highly of Tango that the only issues
being actively debated are the purely stylistic ones.

--
Oskar

Nov 18 2007
Walter Bright <newshound1 digitalmars.com> writes:
Oskar Linde wrote:
To end, I think it speaks very highly of Tango that the only issues
being actively debated are the purely stylistic ones.

It's normal for easily understood issues to get a lot more comments than
the ones that need more work to grok.

However, silence is the worst case <g>. It means nobody has even looked
at it.

Nov 19 2007
Walter Bright <newshound1 digitalmars.com> writes:
David Wilson wrote:
On 11/19/07, Walter Bright <newshound1 digitalmars.com> wrote:
Oskar Linde wrote:
To end, I think it speaks very highly of Tango that the only issues
being actively debated are the purely stylistic ones.

the ones that need more work to grok.

http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING

Spot on.

Nov 19 2007
Matti Niemenmaa <see_signature for.real.address> writes:
Oskar Linde wrote:
I believe shallow hierarchies generally are better than deep, and also
that there should be a functional rather than logical separation between
packages.

So, instead of:

tango.util.collection.iterator.InterleavingIterator

couldn't there just be:

tango.collection.iterators

or perhaps even:

tango.collection

One problem with shoving all iterators into one module is the way the protection
specifiers work in D. As you probably know, private and co are module-level.
This means that InterleavingIterator and TropicalJungleIterator, while
completely distinct, can access each other's privates! The fact that they are in
different modules thus accentuates their independence of each other.

If protection specifiers worked as they do in C++ (and, as a matter of fact, in
just about every other language I know of that implements such a feature), then
a "tango.collection.iterators" package would make more sense. As it is, putting
two classes into the same module suggests that they are tightly coupled and, at
least to me, that they do access each other's private members.

Plus, especially a general-purpose module such as "tango.collection" would grow
to thousands of lines in length. This would make it a pain to code in, but there
are also issues for the user. For instance, the automatically generated DDoc
would also be exceedingly long and would have to manually be separated into
coherent parts.

I do agree that the "tango.util.collection" package should be just
"tango.collection", though. :-)

--
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi

Nov 20 2007
John Reimer <terminal.node gmail.com> writes:
I actuallBill Baxter wrote:
torhu wrote:
Lars Ivar Igesund wrote:
>> Mixed case package/module names are avoided because there needs to
be a
1:1 correspondence between file names and package/module names, and not
all file systems are case sensitive (like FAT32 and NTFS, for a couple
widely used examples).

As I said elsewhere in the thread, other FS _are_ case sensitive, and
thus
you need to be aware of which case you use in either case, rendering the
argument moot. Early on in D history, I encountered several cases of
modules being saved on Windows, then not working on Linux with their
intended module names due to this. And this can only happen if the
Windows
programmer typed in a file name with upper case letters, even though the
module name was all lower case.

I believe Walter's point is that "all package and module names are
lower case" is a simple rule that will help us avoid this problem,
given that everyone does their best to adhere to the rule.  I don't
know how much it matters, since I've never run into the problem
myself.  But I just tried it, and it shouldn't be hard to track down
the problem based on the compiler's error messages.  Not a big deal
either way, it seems.

There is another issue.  Often a module has basically only one main
class in it.  If the main class is called Foo, and that's all that's in
the module, some version of "Foo" is the logical name for the package
too.  But then if you use fully qualified names you end up with
Package.Foo.Foo when referring to the class in the module, which just
look *so* silly that it's easy to forget the second Foo.  But
package.foo.Foo looks more reasonable, since it's clear the second to
last "foo" is not a class name.

I actually think both package.foo.Foo and package.Foo.Foo look bizarre.
I've always disliked this part of D.  In that light, I think it really
is more a shortcoming of the way D does namespaces.  Tango just tries to
work around this (for good or bad... there's seems little choice in the
matter: I believe tango developers and others haggled over this and
other issues long and hard in the past: it wasn't an easy decision).

I'm not sure what might be a good solution to these problems without
"fixing" D. Maybe a more C++ style (horrors!! did I say that?!) would be
useful in differentiating module namespace from class?  I'm not sure...
but that would mean a another D spec change:

such as

package.foo::Foo

as a reference to class Foo (or whatever other symbol one wants to specify)

or package.foo::

as an implied reference to whatever symbol has the same name as module
name... in this case "foo".  If module name "Foo" is capitalized,
therefore, the class or symbol with "Foo" would be selected.

Just some thoughts,

John

Nov 18 2007
Don Clugston <dac nospam.com.au> writes:
John Reimer wrote:

John, it's great to see you back! I feared you were gone forever.
- Don.

Nov 20 2007
John Reimer <terminal.node gmail.com> writes:
Don Clugston wrote:
John Reimer wrote:

John, it's great to see you back! I feared you were gone forever.
- Don.

Don,

You are too kind. :-)

I almost figured I was gone for good too, but it's hard to stay away
from the techy side of life for too long... and D is smack in the center
of it.

Life has been very busy, especially because I'm now apprenticing in log
home construction (www.pioneerloghomesofbc.com) ... a welcome change
from paramedic work (yes, a very unusual change in employment yet
fascinating, nonetheless; it's great to have the opportunity to pick up
these kind of skills).  Anyway, due to winter finally setting in, my
work hours are shorter.  Thus, I've managed a time-slice for D lurking
again among other things (and hopefully a continuation of some
documentation effort). :-D

It's great to see the rapid growth that's been happening around D.
Looks like you have been as creative and productive as ever. ;-)  More
exciting things to come from your end, I can only imagine.

Great to hear from you too, Don. :-)

Take care,

John

Nov 20 2007
John Reimer <terminal.node gmail.com> writes:
John Reimer wrote:
Don Clugston wrote:
John Reimer wrote:

John, it's great to see you back! I feared you were gone forever.
- Don.

Don,

You are too kind. :-)

I almost figured I was gone for good too, but it's hard to stay away
from the techy side of life for too long... and D is smack in the center
of it.

Life has been very busy, especially because I'm now apprenticing in log
home construction (www.pioneerloghomesofbc.com) ... a welcome change
from paramedic work (yes, a very unusual change in employment yet
fascinating, nonetheless; it's great to have the opportunity to pick up
these kind of skills).  Anyway, due to winter finally setting in, my
work hours are shorter.  Thus, I've managed a time-slice for D lurking
again among other things (and hopefully a continuation of some
documentation effort). :-D

It's great to see the rapid growth that's been happening around D. Looks
like you have been as creative and productive as ever. ;-)  More
exciting things to come from your end, I can only imagine.

Great to hear from you too, Don. :-)

Take care,

John

*sigh*

Looking over this thread, I am reminded of the major reason that I left
in the first place (of course, I was partly responsible for it last
time). :-(

Human nature is so ugly.

Nov 21 2007
Don Clugston <dac nospam.com.au> writes:
John Reimer wrote:
John Reimer wrote:
Don Clugston wrote:
John Reimer wrote:

John, it's great to see you back! I feared you were gone forever.
- Don.

Don,

You are too kind. :-)

I almost figured I was gone for good too, but it's hard to stay away
from the techy side of life for too long... and D is smack in the
center of it.

Life has been very busy, especially because I'm now apprenticing in
log home construction (www.pioneerloghomesofbc.com) ... a welcome
change from paramedic work (yes, a very unusual change in employment
yet fascinating, nonetheless; it's great to have the opportunity to
pick up these kind of skills).  Anyway, due to winter finally setting
in, my work hours are shorter.  Thus, I've managed a time-slice for D
lurking again among other things (and hopefully a continuation of some
documentation effort). :-D

It's great to see the rapid growth that's been happening around D.
Looks like you have been as creative and productive as ever. ;-)  More
exciting things to come from your end, I can only imagine.

Great to hear from you too, Don. :-)

Take care,

John

*sigh*

Looking over this thread, I am reminded of the major reason that I left
in the first place (of course, I was partly responsible for it last
time). :-(

Human nature is so ugly.

Indeed.

Your brief exit message on Tango was painful to read.
"Bad advertisement for D" as you deleted your name. Ouch.

Especially since it was a post by you (on a C++ ng I think) that made me give D
a chance in the first place. That's why I'm here.

-Don.

Nov 21 2007
Sean Kelly <sean f4.ca> writes:
Don Clugston wrote:
John Reimer wrote:
Human nature is so ugly.

Indeed.

Your brief exit message on Tango was painful to read.
"Bad advertisement for D" as you deleted your name. Ouch.

Especially since it was a post by you (on a C++ ng I think) that made me
give D a chance in the first place. That's why I'm here.

Yup.  John has always been a valuable member of the D community.  I was
very disappointed to see him leave, though I can understand why one
would not want to deal with the drama.

Sean

Nov 21 2007
"Kris" <foo bar.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
Don Clugston wrote:
John Reimer wrote:
Human nature is so ugly.

Indeed.

Your brief exit message on Tango was painful to read.
"Bad advertisement for D" as you deleted your name. Ouch.

Especially since it was a post by you (on a C++ ng I think) that made me
give D a chance in the first place. That's why I'm here.

Yup.  John has always been a valuable member of the D community.  I was
very disappointed to see him leave, though I can understand why one would
not want to deal with the drama.

Yeah, I fully agree. Good to see him back here!

Nov 21 2007
Sean Kelly <sean f4.ca> writes:
John Reimer wrote:

*sigh*

Looking over this thread, I am reminded of the major reason that I left
in the first place (of course, I was partly responsible for it last
time). :-(

Human nature is so ugly.

Fortunately, with usenet, not being a part of the discussion is as
simple as "mark all read."

Sean

Nov 21 2007
Christopher Wright <dhasenan gmail.com> writes:
Walter Bright wrote:
Sean Kelly wrote:
Janice Caron wrote:
(3) I hate Tango, stylisticly. I hate the mixed case module names, and
the mixed case global variable names (e.g. Stdout). I want everything
to look and feel like Phobos.

I'm not a huge fan of the mixed case global variable names either, but
it does help them stand out, which I think is the point.

Mixed case package/module names are avoided because there needs to be a
1:1 correspondence between file names and package/module names, and not
all file systems are case sensitive (like FAT32 and NTFS, for a couple
widely used examples).

The only way to solve this is to have the DMD frontend do
case-insensitive matching of imports. As it stands, I should be able to
say 'import STD.STDIO;' on Windows/ntfs and have it work, but have it
fail when using ext3. (I don't have a copy of Windows, so I can't check;
and I don't feel like making a case-insensitive fs on my machine right
now. I don't think you put in an explicit check for accurate case, since
if you typed in a command line 'cd phobos/StD/', Windows might update
the case of the folder name.)

This would have a minor benefit of allowing people using tango to write
'import tango.io.stdout;', but using a standard convention also works
decently. It's just that different projects use different conventions,
and I can't use both in my project because of the case insensitive file
systems.

Nov 18 2007
Matti Niemenmaa <see_signature for.real.address> writes:
Christopher Wright wrote:
Walter Bright wrote:
Mixed case package/module names are avoided because there needs to be
a 1:1 correspondence between file names and package/module names, and
not all file systems are case sensitive (like FAT32 and NTFS, for a
couple widely used examples).

The only way to solve this is to have the DMD frontend do
case-insensitive matching of imports. As it stands, I should be able to
say 'import STD.STDIO;' on Windows/ntfs and have it work, but have it
fail when using ext3. (I don't have a copy of Windows, so I can't check;
and I don't feel like making a case-insensitive fs on my machine right
now. I don't think you put in an explicit check for accurate case, since
if you typed in a command line 'cd phobos/StD/', Windows might update
the case of the folder name.)

This would have a minor benefit of allowing people using tango to write
'import tango.io.stdout;', but using a standard convention also works
decently. It's just that different projects use different conventions,
and I can't use both in my project because of the case insensitive file
systems.

import StD.sTdIo;
void main() { writefln("hello world"); }

Compiles and runs on Windows.

--
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi

Nov 18 2007
Sean Kelly <sean f4.ca> writes:
Janice Caron wrote:
On 11/16/07, Alexander Panek <alexander.panek brainsware.org> wrote:

As said - you could as well put the Phobos sources into Tango's std
folder and *tweak* those.

As I mentioned, I did not copy tango's std folder at all. I am doing
without it.

So do you have a /std directory at all?  I would hope so, or some
portions of Tango won't work.  The instrinsic functions, for example,
must have a mangled name that begins with "std".  This is unfortunate,
but what can you do.

Sean

Nov 16 2007
Sean Kelly <sean f4.ca> writes:
Janice Caron wrote:
On 11/16/07, Sean Kelly <sean f4.ca> wrote:

As I mentioned, I did not copy tango's std folder at all. I am doing
without it.

I have Phobos's std directory. It is completely unchanged and intact.
(And obviously it will be updated the moment D2.008 comes along).

Oh, that's fine then.  The /std directory included with Tango just
contains cleaned-up copies of the Phobos files Tango needs.

Sean

Nov 16 2007
Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:
"Janice Caron" wrote
I've started to like Tango, now that I've got bits of it working with
Phobos :-)

With a bit of kludging, I've persuaded all of the examples in the
"console" and "text" directories to build with Phobos using DMD 2.007.
Of the examples files, only "properties.d" needed to be tweaked
slightly - and that was just to replace "char[]" with "string".

Just an FYI, some of us are working on a D 2.x compatible version of Tango.

Basically the hard part is adding const.

It's not release-ready yet, but I'm hoping once Walter has fixed const, we
should be able to finish the port.

Of course, it does not use Phobos... But hopefully that problem will be
solved soon also.

The const stuff is changing significantly (for the much better, I hope),
so be prepared to do another pass over it if you are adapting it to
const. I've found the necessary changes to the source to be simple to do
(and they are flagged by the compiler), so it shouldn't be a problem.

Nov 18 2007
"Janice Caron" <caron800 googlemail.com> writes:
On 11/15/07, Steven Schveighoffer <schveiguy yahoo.com> wrote:
Just an FYI, some of us are working on a D 2.x compatible version of Tango.

Yeah, well that's kind of what I did. I took the source in the "tango"
dir (i.e. not the "std" dir, not "object.d"), and then did

foreach(example)
while(does not compile)
fix_first_error()

Basically the hard part is adding const.

I noticed. I liberally added const and invariant everywhere I could
get away with it. It takes some fine tuning to get it right. D strings
are invariant now, so I had to throw in some idups in places where I
couldn't prove to myself that the original was actually unique.

I also changed toUtf to toString, and changed all the module names to lowercase.

It's not release-ready yet, but I'm hoping once Walter has fixed const, we
should be able to finish the port.

I'm working with 2.007. I assume it will be not too hard to upgrade.

Of course, it does not use Phobos...

Mine does. I specifically do not use Tango's object.d, nor anything in
Tango's std. I'm importing phobos and my bastardised version of Tango
simultaneously.

It's actually quite fun.

Nov 15 2007
"Janice Caron" <caron800 googlemail.com> writes:
On 11/15/07, Jarrett Billingsley <kb3ctd2 yahoo.com> wrote:
Anyway, someone tell me - does Tango have containers? If so, are there
any examples of use in the "examples" folder of the Tango download? I
couldn't find any.

http://www.dsource.org/projects/tango/docs/current/ is useful indeed.  Yes,
there are containers, in tango.util.collection.

I don't want docs, I want example source code. I want something I can
compile, with tests to prove it's all working. Is there not a
test-suite handy?

Nov 15 2007
"Janice Caron" <caron800 googlemail.com> writes:
On 11/15/07, Frank Benoit <keinfarbton googlemail.com> wrote:
and all the snippets are here

examples/manual/chapterStorage.d

That's what I was looking for! Great! :-)

The folder name ("manual") didn't really make it obvious what was in
it. Guess I'll attack that one next.

Nov 15 2007
Alexander Panek <alexander.panek brainsware.org> writes:
On Thu, 15 Nov 2007 23:09:55 +0000
"Janice Caron" <caron800 googlemail.com> wrote:
Of course, it does not use Phobos...

Mine does. I specifically do not use Tango's object.d, nor anything in
Tango's std. I'm importing phobos and my bastardised version of Tango
simultaneously.

Actually, the core of Tango is in tango.core - the std/ folder is just
there because DMD requires the intrinsic module to be there, IIRC.

Just curious: why don't you use Tango and the freestanding functions of
Phobos (AFAIK most of them interface with C, anyways - which can be
done in Tango, too, of course)? I suppose that would be less work to
achieve the same goal (oh, and btw, you'll have a less buggy
runtime.. /me hides.)

Kind regards
--
Alexander Panek <alexander.panek brainsware.org>

Nov 15 2007
"Janice Caron" <caron800 googlemail.com> writes:
On 11/16/07, Alexander Panek <alexander.panek brainsware.org> wrote:
Actually, the core of Tango is in tango.core

Yeah, I've tweaked my copies of several of files in core already.

- the std/ folder is just
there because DMD requires the intrinsic module to be there, IIRC.

I didn't understand that, but hey ho. In any case, the original Phobos
std is still there in my case.

Just curious: why don't you use Tango and the freestanding functions of
Phobos

Lot of reasons.

(1) If an engine ain't broke, don't fix it.

(2) I like D2.007, and I'll be switching to D2.008 the day it comes out.

(3) I hate Tango, stylisticly. I hate the mixed case module names, and
the mixed case global variable names (e.g. Stdout). I want everything
to look and feel like Phobos.

(4) Walter has been doing this for seven years or whatever, and has
earned my greatest respect. Ripping out the innards of D scares the
shit out of me - and not only that, I see no reason why I should have
to.

This way, I get to use the latest cutting-edge version of D, I can
make all the module names lowercase (yes, that matters!), and though
things like Stdout(x).newline compile and run, I don't have to use
them - I'll be able to throw in nicer looking functions that do the
same thing.

Nov 16 2007
Alexander Panek <alexander.panek brainsware.org> writes:
On Fri, 16 Nov 2007 08:17:42 +0000
"Janice Caron" <caron800 googlemail.com> wrote:

On 11/16/07, Alexander Panek <alexander.panek brainsware.org> wrote:
Actually, the core of Tango is in tango.core

Yeah, I've tweaked my copies of several of files in core already.

My apologies - ... tweaked?

- the std/ folder is just
there because DMD requires the intrinsic module to be there, IIRC.

I didn't understand that, but hey ho. In any case, the original Phobos
std is still there in my case.

As said - you could as well put the Phobos sources into Tango's std
folder and *tweak* those.

Just curious: why don't you use Tango and the freestanding
functions of Phobos

Lot of reasons.

(1) If an engine ain't broke, don't fix it.

I think there are people who definitely wouldn't agree on that. But I
am not in the qualified position to argue about that.

(3) I hate Tango, stylisticly. I hate the mixed case module names, and
the mixed case global variable names (e.g. Stdout). I want everything
to look and feel like Phobos.

No comment on that.

(4) Walter has been doing this for seven years or whatever, and has
earned my greatest respect. Ripping out the innards of D scares the
shit out of me - and not only that, I see no reason why I should have
to.

It scares you? Why?

This way, I get to use the latest cutting-edge version of D, I can
make all the module names lowercase (yes, that matters!), and though
things like Stdout(x).newline compile and run, I don't have to use
them - I'll be able to throw in nicer looking functions that do the
same thing.

You know, there's still printf in tango.stdc.stdio ..... just in
case. :P

--
Alexander Panek <alexander.panek brainsware.org>

Nov 16 2007
"Janice Caron" <caron800 googlemail.com> writes:
On 11/16/07, Bill Baxter <dnewsgroup billbaxter.com> wrote:
I thought we agreed that this should be called "Phandango".  :-)

Well, there isn't really an "it". I was actually getting this working
just for me. I wasn't planning on uploading it anywhere because the
/real/ Tango is being made Phobos compatible, as I understand it, and
we should all just wait for that. Anyone who's impatient could do what
I did, I guess, or maybe I could show my source anyway, but I make no
claims that it's in any way "official". As for the name, it is the
work of /seconds/ to search and replace, and name it anything you
want.

Nov 16 2007
"Janice Caron" <caron800 googlemail.com> writes:
On 11/16/07, Alexander Panek <alexander.panek brainsware.org> wrote:
On Fri, 16 Nov 2007 08:17:42 +0000
"Janice Caron" <caron800 googlemail.com> wrote:

On 11/16/07, Alexander Panek <alexander.panek brainsware.org> wrote:
Actually, the core of Tango is in tango.core

Yeah, I've tweaked my copies of several of files in core already.

My apologies - ... tweaked?

Well yeah. As I said at the start of this thread, what I did was:

foreach(example)
while(does not compile)
fix_first_error()

So if the compiler tells me that A won't cast to B because of some
invariant issue or some-such, then I modified the source in the
offending file. If that happened to be tango.core (actually I renamed
it phango.core to avoid confusion) then so be it.

As said - you could as well put the Phobos sources into Tango's std
folder and *tweak* those.

As I mentioned, I did not copy tango's std folder at all. I am doing
without it. I am not interested in messing around with D's standard
library (Phobos) in any way. In fact, I sometimes have had to call on
its services (e.g. std.contracts.assumeUnique()) to get things to
compile.

It scares you? Why?

Because it might stop something upon which I already rely from working

You know, there's still printf in tango.stdc.stdio ..... just in

True. But that's not really an issue for what I'm doing. If I can be
bothered, I might find a way to add cout.writefln() and
stdout.writefln() or whatever, to give me Phobos syntax with Tango's
streams. But right now I've still got Phobos's writef() and writefln()
functions at my disposal, so I'm perfectly happy.

Besides ... printf()? Now there's a function that really should be deprecated!

Nov 16 2007
"Janice Caron" <caron800 googlemail.com> writes:
On 11/15/07, Janice Caron <caron800 googlemail.com> wrote:
examples/manual/chapterStorage.d

That's what I was looking for! Great! :-)

The folder name ("manual") didn't really make it obvious what was in
it. Guess I'll attack that one next.

That was easy!

Obviously, chapterstorage.d was not written for D2+, so I had to
change all the char[]s into strings in that file.

Anyway, all I had to do was change char[] into string in the source
files, except in toUpper and toLower, and guess what - it compiled
without complaint, and runs perfectly. Woo hoo!

Nov 16 2007
Alexander Panek <alexander.panek brainsware.org> writes:
On Fri, 16 Nov 2007 12:46:24 +0000
"Janice Caron" <caron800 googlemail.com> wrote:

Obviously, chapterstorage.d was not written for D2+, so I had to
change all the char[]s into strings in that file.

As you might know already or at least have guessed - since there's an
experimental  Tango /branch/ for D 2.x -, Tango is D 1.x only, right
now. So it'd be pretty weird to write the reference manual of Tango for
D 2.x. :)

--
Alexander Panek <alexander.panek brainsware.org>

Nov 16 2007
"Janice Caron" <caron800 googlemail.com> writes:
I dunno if you'd consider this a bug in tango.io.filepath.parse(), but
the example program filepathname.d looks like this:

void main(){
Cout ((new FilePath(r"d:\path\foo.bat")).name).newline;
Cout ((new FilePath(r"d:\path.two\bar")).name).newline;
Cout ((new FilePath("/home/user.name/bar.")).name).newline;
Cout ((new FilePath(r"d:\path.two\bar")).name).newline;
Cout ((new FilePath("/home/user/.resource")).name).newline;
}

And (on Windows) emits the following output - at least, on my ported version:

foo
bar
/home/user.name/bar
bar
/home/user/

I think I understand what's going on here. The slash in the third and
fifth examples is being (incorrectly) regarded as a component
character, instead of a path separator, so it thinks "/home/user/" is
the file part and "resource" the extension.

Yes, I know there's a flag in the constructor which converts "\" to
"/", and that that flag wasn't set in this example, BUT...

In Windows, "\" and "/" are BOTH acceptable as file separators. As far
as fopen() is concerned, they are interchangable. If you open
"/home/user/.resource" you'll get exactly the same file as had you
opened "\home\user\.resource".

This isn't true in a Windows (Command Prompt) shell, however, even
there, "/" is not a valid character for use in filenames. In fact, all
of the characters \ / : * ? " < > and | are prohibited from being used
in filenames.

I feel that the filepath.parse routine really should understand how
pathnames actually work on Windows. Sure, if the native flag is set,
then convert / to \. But even if that doesn't happen, parse() should
recognise both \ and / as pathname separators, and should throw an
exception if an illegal character is used in a pathname.

If there are no objections, I plan to "fix" this in my local copy, and
I can certainly post the fix for you, in case you should want to
incorporate it into the real Tango.

Nov 16 2007
"Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Janice Caron" wrote
I dunno if you'd consider this a bug in tango.io.filepath.parse(), but
the example program filepathname.d looks like this:
...

Register at dsource: http://www.dsource.org/forums/profile.php?mode=register
File a ticket on tango: http://www.dsource.org/projects/tango/newticket.

It's actually a pretty nice system, and the developers are very responsive.

-Steve

Nov 16 2007
"Janice Caron" <caron800 googlemail.com> writes:
On 11/16/07, Sean Kelly <sean f4.ca> wrote:

As I mentioned, I did not copy tango's std folder at all. I am doing
without it.

So do you have a /std directory at all?

I have Phobos's std directory. It is completely unchanged and intact.
(And obviously it will be updated the moment D2.008 comes along).

I would hope so, or some
portions of Tango won't work.

Given that I have (a now modified copy of) the source code, and the
power and ability to change it. I can make anything work.

The instrinsic functions, for example,
must have a mangled name that begins with "std".

None of the examples I've got working have given me this problem so
far, but I'm fair sure that if something doesn't work, I can just
change the source until it does.

Nov 16 2007
"David Wilson" <dw botanicus.net> writes:
On 11/19/07, Walter Bright <newshound1 digitalmars.com> wrote:
Oskar Linde wrote:
To end, I think it speaks very highly of Tango that the only issues
being actively debated are the purely stylistic ones.

It's normal for easily understood issues to get a lot more comments than
the ones that need more work to grok.

http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING

However, silence is the worst case <g>. It means nobody has even looked
at it.


Nov 19 2007