Johan Granberg Wrote:
> 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.

A file doesn't require any sort of class in order to manipulate.  It's a raw stream of data.  Enter void[].  Want it to be a wchar[]?  cast() is a wonderful way to do it.  Want to slice off a chunk?  Want to perform something on it?  Cast it, run it through a function via the notation I suggested earlier.

Walter thought of this when he designed the language, and was considered it a design feature that you didn't need to make classes to support primitives.

That said, I can see if someone needs to perform operator overloading, wrapping it in a struct (which is transparent and smaller than a class) and then going to it.

Classes are inherently big.  Want to call a method?  It looks up the offset inside an (offsite?) vtbl, and then you lookup &this+offset and call that.  2-6 extra cycles can be trivial, but an offsite vtbl would mean potential cache misses and that's just to call a method, *everything* with classes is messier that way.

I honestly don't think classes should *never* be used, I just think they should be used sparingly, when you actually *need* the functionality that a class offers.

Occams Razor.

Alexander Panek wrote:
> 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.
> 

That's true. Sometimes, however, a hackish method is best.

Maybe it's just my general "OO only where it's needed" philosophy showing itself: I'd rather read the raw file contents and work with that, than inherit a Tango file class, redefining methods to handle whatever file format I'm dealing with --- this, I suppose, is what would be the proper "less hackish" method in this case.

-- 
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.
> 

The only state contained in File is a FilePath instance.  Which means
you can do things like this:

auto f = new File("name");

if (f.path.exists)
     auto x = f.read();
else
     printf("file not found!\n");

But since you would probably wrap the whole thing in a try-catch block anyway, I'm not sure I'd ever do it like that.  On the other hand, you could also create the file, delete it, get its size etc.

So File basically combines FilePath and FileConduit into a single class, that's pretty easy to use.  But since the FileConduit part is the most useful aspect of File, I'd also be more than happy if Tango just provided free functions to read, write, append etc.

All in all, I haven't used Tango enough myself to really have an informed opinion about this issue.  Other people might, though.

== Quote from Sean Kelly (sean@f4.ca)'s article

> 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.

Out of interest, have you seen Andrei's "The Power of None" paper? Quite a cute approach to this problem, and IIRC it should be doable in D.

cheers
Mike

%u wrote:

> The Power of None

Link?

Johan Granberg wrote:
> %u wrote:
> 
>> The Power of None
> 
> Link?

I found some slides at http://www.nwcpp.org/Meetings/2006/05.html which explained the concept quite well.

Very very very cool! We'll use it for sure in our C++ works!
But is it really doable in D?
What about the casts? Or about the GC, and the throws in the destructors when the Likely goes out of scope?

cheers, Paolo

%u wrote:
> == Quote from Sean Kelly (sean@f4.ca)'s article
> 
>> 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.
> 
> Out of interest, have you seen Andrei's "The Power of None" paper? Quite a cute
> approach to this problem, and IIRC it should be doable in D.
> 
> cheers
> Mike

Paolo Invernizzi wrote:
> Very very very cool! We'll use it for sure in our C++ works!
> But is it really doable in D?
> What about the casts? Or about the GC, and the throws in the destructors when the Likely goes out of scope?

I haven't looked at the slides yet, but it is illegal to throw an exception from a dtor in D, just as in C++.  Doing so in Tango will cause the app to exit under normal circumstances.


Sean

Sean Kelly wrote:
> Paolo Invernizzi wrote:
>> Very very very cool! We'll use it for sure in our C++ works!
>> But is it really doable in D?
>> What about the casts? Or about the GC, and the throws in the
>> destructors when the Likely goes out of scope?
> 
> I haven't looked at the slides yet, but it is illegal to throw an exception from a dtor in D, just as in C++.

It's not illegal in C++, just generally ill-advised
as it will terminate() the program if it occurs
during stack unwinding while another exception is
active.

-- James

James Dennett wrote:
> Sean Kelly wrote:
>> Paolo Invernizzi wrote:
>>> Very very very cool! We'll use it for sure in our C++ works!
>>> But is it really doable in D?
>>> What about the casts? Or about the GC, and the throws in the
>>> destructors when the Likely goes out of scope?
>> I haven't looked at the slides yet, but it is illegal to throw an
>> exception from a dtor in D, just as in C++. 
> 
> It's not illegal in C++, just generally ill-advised
> as it will terminate() the program if it occurs
> during stack unwinding while another exception is
> active.

True enough.  Throwing from a dtor isn't illegal, just effectively prohibited.  It's more than just a popular convention though, since many STL classes provide nothrow guarantees from their dtors.


Sean