Tomas Lindquist Olsen wrote:
> Bill Baxter wrote:
> 
>> Tangobos will be great.  Can't wait.
>> How are you going to deal with toString/toUtf8?
> 
> If you look at the tango object.di, there is a version(PhobosCompatibility)
> block which aliases toUTF8->toString

That still doesn't allow classes to override toString (they'd still need to override toUtf8).
Perhaps this should be filed as an enhancement request at IssueZilla (allowing classes to override aliases of member functions)?

As I just said in a different thread.  Tango has this OO gleam in it's eye.  It's implementing classes for the craziest of things.  Strings don't need a class!  Implementing a class to store an array is *hugely* wasteful.

Especially since you can already use:

char[] foo(char[] s){
 s ~= " world";
}

char[] myS = "hello";

myS.foo();

Classes are the Microsoft Windows of the programming world; opague, costly, slow, and they have burdensome licensing.

Dan wrote:
> As I just said in a different thread.  Tango has this OO gleam in it's eye.  It's implementing classes for the craziest of things.  Strings don't need a class!  Implementing a class to store an array is *hugely* wasteful.

For the most part, I think Tango is OO when appropriate.  The objects that exist do so to retain state, and it is rarely, if ever, necessary for a user to define their own objects to use Tango.  But that aside, a String is an object, be it a class or a struct.  I suppose there's no reason for it not to be a struct--it simply hasn't come up before, and no one has ever complained.

> Especially since you can already use:
> 
> char[] foo(char[] s){
>  s ~= " world";
> }
> 
> char[] myS = "hello";
> 
> myS.foo();

Yup.  Tango may have a String class, but it isn't used very often.  Its real advantage in my opinion is UniString, a generic parent class for String which doesn't restrict the underlying char type.  This isn't something that's available with built-in arrays.

> Classes are the Microsoft Windows of the programming world; opague, costly, slow, and they have burdensome licensing.

I disagree.  Heap allocation may be slower than stack allocation, but reference passing is fast, and it is often useful to have control over copy semantics and such.  Also, guaranteed reference semantics have some very real advantages in terms of what's possible in a language.


Sean

Dan wrote:
> As I just said in a different thread.  Tango has this OO gleam in it's eye.  It's implementing classes for the craziest of things.  Strings don't need a class!  Implementing a class to store an array is *hugely* wasteful.
[snip]

I think you may be a bit confused. Nobody was talking about a string class here.
What we were talking about was the fact that Tango has renamed Object.toString (which returns char[]) to object.toUtf8, and now when compiled with -version=PhobosCompatibility has "alias toUtf8 toString;" added to Object.

I was pointing out that classes that override toString won't work even with that line added, since aliases can't be overridden.

Dan wrote:
> As I just said in a different thread.  Tango has this OO gleam in it's eye. It's implementing classes for the craziest of things.  Strings don't need a class!  Implementing a class to store an array is *hugely* wasteful.
> 

From what I understand, the string class in Tango is handy because it handles Unicode text on the code point level. Thus you don't need to worry about whether it's in UTF-8, -16, or -32, and how this affects stuff like slicing.

Of course, there's still the problem of combining characters and ligatures.

> Classes are the Microsoft Windows of the programming world; opague, costly, slow, and they have burdensome licensing.

I don't quite agree with this, but I do prefer free functions in many cases. I can accept having a File class for "heavy-duty" file handling, but I still find myself missing a simple function for just dumping an ubyte[] array of a file's contents.

The "problem" is that Tango is currently just so much *better* than Phobos, idioms aside.

-- 
Remove ".doesnotlike.spam" from the mail address.

Deewiant wrote:
> [...] I don't quite agree with this, but I do prefer free functions in many cases. I
> can accept having a File class for "heavy-duty" file handling, but I still find
> myself missing a simple function for just dumping an ubyte[] array of a file's
> contents.

http://dsource.org/projects/tango/docs/current/tango.io.File.html

auto contentOfAFile = (new File( "filename" )).read;

There you go.

Deewiant wrote:
> 
> I don't quite agree with this, but I do prefer free functions in many cases. I
> can accept having a File class for "heavy-duty" file handling, but I still find
> myself missing a simple function for just dumping an ubyte[] array of a file's
> contents.

I prefer free functions in many cases as well.  However, different people have different needs in this area.  Some may want such functions to throw an exception on error, others may want a return code, etc. With this in mind, I feel it is often more appropriate to let the programmer define such things for themselves.  Particularly since the process is typically trivial.  The only issue with wrapping object libraries is the risk of overhead from the construction of disposable objects, but between 'scope' allocation for classes and Tango's tendency towards highly efficient designs (IMO), I don't think that's a concern here.


Sean

Sean Kelly wrote:
> I prefer free functions in many cases as well.  However, different people have different needs in this area.  Some may want such functions to throw an exception on error, others may want a return code, etc. With this in mind, I feel it is often more appropriate to let the programmer define such things for themselves.  Particularly since the process is typically trivial.  The only issue with wrapping object libraries is the risk of overhead from the construction of disposable objects, but between 'scope' allocation for classes and Tango's tendency towards highly efficient designs (IMO), I don't think that's a concern here.
> 
> 
> Sean

I disagree whit it being appropriate to leave the creation of shorthand functions to the users of a library. Of course it's unfeasible to define all the functions potential users might need but I think thouse most needed or used should be defined in the library. This can help to reduse code size of small programs or modules significantly. Regarding the exceptions or error codes issue it could be solved either by providing to versions of the utility functions or by choosing one of them, in the later case the rational is that it is easier to only have to do error handling yourself rather that having to do both error handling and class wrapping.

Othervise tango looks great and much more compleat than phobos.

Alexander Panek wrote:
> Deewiant wrote:
>> [...] I don't quite agree with this, but I do prefer free functions in
>> many cases. I
>> can accept having a File class for "heavy-duty" file handling, but I
>> still find
>> myself missing a simple function for just dumping an ubyte[] array of
>> a file's
>> contents.
> 
> http://dsource.org/projects/tango/docs/current/tango.io.File.html
> 
> auto contentOfAFile = (new File( "filename" )).read;
> 
> There you go.

Of course. But I feel uneasy with throwaway objects, like I'm fighting the library. There's probably no good reason to, but I do.

-- 
Remove ".doesnotlike.spam" from the mail address.

Deewiant wrote:
> Alexander Panek wrote:
>> Deewiant wrote:
>>> [...] I don't quite agree with this, but I do prefer free functions in
>>> many cases. I
>>> can accept having a File class for "heavy-duty" file handling, but I
>>> still find
>>> myself missing a simple function for just dumping an ubyte[] array of
>>> a file's
>>> contents.
>> http://dsource.org/projects/tango/docs/current/tango.io.File.html
>>
>> auto contentOfAFile = (new File( "filename" )).read;
>>
>> There you go.
> 
> Of course. But I feel uneasy with throwaway objects, like I'm fighting the
> library. There's probably no good reason to, but I do.
> 

I can understand that. I've got an issue with throw away objects, too, but given the fact, that you just want a file's content no matter what format it is... the whole process is a bit hackish, and I'd recommend to use other, less hackish solutions of tango's IO package. Even if that would mean two lines of source code more, you won't have throw away, and a proper, tested way of reading data from a file.

Kind regards,
Alex