One of the patches here

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3170

removes the print method from class Object.  Walter seems to be hesitating to put it in.

It isn't clear to what extent removing it would break existing code. However, it's certainly time to deprecate it IMO.

The patch I've just posted here

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/4368

has the by-product of cutting out the use of Object.print that I know of (maybe there are others).

It isn't clear why Object.print exists when we have Object.toString.  If a program wants to output the string representation of something, it can use .toString directly, which is much more versatile.  While in theory print could be overridden e.g. to show more information than would appear in the toString, this isn't the way to do it.

The problem is that Object.print gives the application no control over what to output to.  Even when faced with the same class, different applications (or indeed parts of the same application) might want to write the data to stdout, stderr, a log file or a GUI window, just to name a few possibilities.  A single .print method with no parameters doesn't give the class user the choice.

If a class designer wants to provide a means of generating 'long' output distinct from the .toString behaviour, it can provide its own method, maybe called toLongString or something similar.  This would simply return the 'long' output and let the caller do what it wants with it. Then an application that wants access to this output, either to output it to whatever or to parse/manipulate it, can call this method.  Then, the only question that remains is whether toLongString should be in Object.  I personally don't see any point at the moment in putting it in ... but does anyone?...

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> One of the patches here
> 
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3170
> 
> removes the print method from class Object.  Walter seems to be hesitating to put it in.
> 
> It isn't clear to what extent removing it would break existing code. However, it's certainly time to deprecate it IMO.
> 
> The patch I've just posted here
> 
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/4368
> 
> has the by-product of cutting out the use of Object.print that I know of (maybe there are others).
> 
> It isn't clear why Object.print exists when we have Object.toString.  If a program wants to output the string representation of something, it can use .toString directly, which is much more versatile.  While in theory print could be overridden e.g. to show more information than would appear in the toString, this isn't the way to do it.
> 
> The problem is that Object.print gives the application no control over what to output to.  Even when faced with the same class, different applications (or indeed parts of the same application) might want to write the data to stdout, stderr, a log file or a GUI window, just to name a few possibilities.  A single .print method with no parameters doesn't give the class user the choice.
> 
> If a class designer wants to provide a means of generating 'long' output distinct from the .toString behaviour, it can provide its own method, maybe called toLongString or something similar.  This would simply return the 'long' output and let the caller do what it wants with it. Then an application that wants access to this output, either to output it to whatever or to parse/manipulate it, can call this method.  Then, the only question that remains is whether toLongString should be in Object.  I personally don't see any point at the moment in putting it in ... but does anyone?...
> 
> Stewart.
> 

I've used it for...

int main()
{

   try
   {
      throw new Exception("An Exception Has Occured!");
   }
   catch (Exception e)
   {
      e.print();
   }

   return 0;
}

But I guess I could use

writefln(e.toString);

instead

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:d965hk$lc2$1@digitaldaemon.com...

I totally agree with everything you said.  However, there is a problem with interfacing with classes in older libs.  Since .print() is in EVERY class in D, it is part of the vtable.  Removing the .print() function would cause interfaces to not work to the older libs anymore, as the vtable would be off for just about every function.  The libs would have to be recompiled with the new Object base class.  It should be deprecated, at least.

In article <d965hk$lc2$1@digitaldaemon.com>, Stewart Gordon says...
>
>One of the patches here
>
>http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3170
>
>removes the print method from class Object.  Walter seems to be hesitating to put it in.
>
>It isn't clear to what extent removing it would break existing code. However, it's certainly time to deprecate it IMO.

I did this a while back in Ares, and I can think of one one reason for keeping print() in place: it facilitates displaying meaningful error messages when exceptions are thrown in an out of memory condition.  But were this sufficient reason to keep it, I'd vote for moving it into Exception and dropping it from Object.


Sean

In article <d9702j$196k$1@digitaldaemon.com>, Sean Kelly says... <snip>
> I did this a while back in Ares, and I can think of one one reason for keeping print() in place: it facilitates displaying meaningful error messages when exceptions are thrown in an out of memory condition.  But were this sufficient reason to keep it, I'd vote for moving it into Exception and dropping it from Object.

Huh?  What do you mean by this?

Stewart.

In article <d971rm$1an0$1@digitaldaemon.com>, Stewart Gordon says...
>
>In article <d9702j$196k$1@digitaldaemon.com>, Sean Kelly says... <snip>
>> I did this a while back in Ares, and I can think of one one reason for keeping print() in place: it facilitates displaying meaningful error messages when exceptions are thrown in an out of memory condition.  But were this sufficient reason to keep it, I'd vote for moving it into Exception and dropping it from Object.
>
>Huh?  What do you mean by this?

It's not uncommon for toString to allocate memory for the returned string, while print just dumps the info to stderr.  For system errors, allocating memory before they've been handled is a risky proposition.  But upon reflection I see no reason not to just require such exceptions to not allocate memory in their toString methods and if the user attempts to manipulate the string returned by toString that's their problem.  I just cleaned up the Ares code with this in mind.


Sean

Sean Kelly wrote:
<snip>
> It's not uncommon for toString to allocate memory for the returned string, while
> print just dumps the info to stderr.  For system errors, allocating memory
> before they've been handled is a risky proposition. 

This implies that it may be a Bad Thing to allocate memory for the returned string before throwing the exception.  But if OTOH it's during the error recovery that this happens (which tends to be so anyway, if the toString method generates the string on the fly), then by this time some pointers into the GC heap may have gone out of scope and so there may be some memory left.

And forcing the programmer to duplicate effort by maintaining toString and print in parallel might not be the Right Thing - indeed it could be a source of bugs.

> But upon reflection I see
> no reason not to just require such exceptions to not allocate memory in their
> toString methods and if the user attempts to manipulate the string returned by
> toString that's their problem.  I just cleaned up the Ares code with this in
> mind.

If a class is going to use D library functions to generate an exception string, it's not unlikely that some memory'll be allocated in the process.  And even if you use C functions, you'll still need somewhere to put it.  And so how would generation of a personalised error string work at all?

I guess it's a matter of what kinds of errors are likely to occur in the process of recovering from an OutOfMemoryException.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

In article <d98nav$2m10$1@digitaldaemon.com>, Stewart Gordon says...
>
>Sean Kelly wrote:
><snip>
>> It's not uncommon for toString to allocate memory for the returned string, while print just dumps the info to stderr.  For system errors, allocating memory before they've been handled is a risky proposition.
>
>This implies that it may be a Bad Thing to allocate memory for the returned string before throwing the exception.  But if OTOH it's during the error recovery that this happens (which tends to be so anyway, if the toString method generates the string on the fly), then by this time some pointers into the GC heap may have gone out of scope and so there may be some memory left.

True enough.

>And forcing the programmer to duplicate effort by maintaining toString and print in parallel might not be the Right Thing - indeed it could be a source of bugs.

Good point.

>If a class is going to use D library functions to generate an exception string, it's not unlikely that some memory'll be allocated in the process.  And even if you use C functions, you'll still need somewhere to put it.  And so how would generation of a personalised error string work at all?

It wouldn't.  But I think this is acceptable for system errors--at least at the throw site.  When caught, the user could call a function to get a more detailed description if possible, like what happens in Windows code.  Unless the error thrown was an OutOfMemoryError, this is quite likely to work.  And as you say above, it may even work for OutOfMemory, since memory may have been released during stack unrolling.


Sean

Sean Kelly wrote:
<snip>
>> If a class is going to use D library functions to generate an exception string, it's not unlikely that some memory'll be allocated in the process.  And even if you use C functions, you'll still need somewhere to put it.  And so how would generation of a personalised error string work at all?
> 
> It wouldn't.  But I think this is acceptable for system errors--at least at the throw site.  When caught, the user could call a function to get a more detailed description if possible, like what happens in Windows code.

So every system error would have a constant (or generated in advance) error string, but other errors can have made-to-measure ones?

> Unless the error thrown was an OutOfMemoryError, this is quite likely to work.  And as you say above, it may even work for OutOfMemory, since memory may have been released during stack unrolling.

But we can't rely on this.  Moreover, what specific information about an OutOfMemoryException (as it's called now) could we feasibly extract? And considering that there's only one pseudo-instance of OutOfMemoryException, which is thrown each time....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

In article <d999f0$6dc$1@digitaldaemon.com>, Stewart Gordon says...
>
>Sean Kelly wrote:
><snip>
>>> If a class is going to use D library functions to generate an exception string, it's not unlikely that some memory'll be allocated in the process.  And even if you use C functions, you'll still need somewhere to put it.  And so how would generation of a personalised error string work at all?
>> 
>> It wouldn't.  But I think this is acceptable for system errors--at least at the throw site.  When caught, the user could call a function to get a more detailed description if possible, like what happens in Windows code.
>
>So every system error would have a constant (or generated in advance) error string, but other errors can have made-to-measure ones?

I don't know that it's necessary for non-system errors to be so careful.  They would likely be thrown as a result of some logic failure, and it would be unlikely for this to coincide with an out of memory condition (without an OutOfMemoryError being thrown first).  That said, there is a group in the C++ camp that says no DMA should ever occur at an exception throw site, because You Never Know.  I think this is a fair statement, but then I wonder why std::runtime_error carried a std::string with it.  Also, as classes in D do not have value semantics, it's difficult to throw an exception without any DMA at all.  And if you're allocating memory for an exception, why not an error message as well?

>> Unless the error thrown was an OutOfMemoryError, this is quite likely to work.  And as you say above, it may even work for OutOfMemory, since memory may have been released during stack unrolling.
>
>But we can't rely on this.  Moreover, what specific information about an OutOfMemoryException (as it's called now) could we feasibly extract?

None.  An OutOfMemory error in D is thrown from the GC, so we don't even have a file/line number to carry.

>And considering that there's only one pseudo-instance of OutOfMemoryException, which is thrown each time....

Yup.  The other system errors typically carry file and line numbers, but OutOfMemoryError is just that.  All you can really do is identify the error and try to free some memory, or just abort.


Sean