Daniel Yokomiso wrote:
> 
> Hi,
>     Comments embedded.
> 
> "Helmut Leitner" <helmut.leitner@chello.at> escreveu na mensagem

I recently saw this a number of times from different contributors obviously as a result from the top/bottom discussion.

But I think it isn't helpful. If there is no top comment any reader will automatically assume that there are embedded comments.

There is no need to comment the obvious.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

"Helmut Leitner" <leitner@hls.via.at> escreveu na mensagem news:3F49C52E.801A1879@hls.via.at...
> Daniel Yokomiso wrote:
> > > It's important to be able to focus e. g. all Error and Exception
handling
> > > in a project. The only efficient way to do so is be text search for
the
> > > words "Error" or "Exception".
> >
> >     Or use a tool to do structural search for Error and Exception. Once
the
> > D syntax get stable and we have a general parser for it, we could create
(I
> > am volunteering to write this) a framework for searching, refactoring,
etc.
> > There's no need to do these things if exist tools for that (either
graphic
> > or textual).
>
> While these tools do not exist or aren't in a perfect state, it's good to be able to rely on good old text search. Why not keep it simple?
>
> I often found the tools fall short when you leave their path. E.g.
>   - if you want to search a project that doesn't compile
>   - if you want to search multiple projects
>   - if you want to search through many revisions of the same project

"old text search" fall short on several issues:
   - if you want to search for instances of some class or it's subclasses
   - trying to find all callers of a certain method through certain
interface
   - giving a useful summary of available methods through an class/interface
(like the Eiffel "short" tool).

Plain textual search is useful, but if you want to do more comprehensive searches you need either to adopt a naming convention (appending or prepending names/letters) or try to come up with some regex to match what you're are looking for.

> Yes of course. Such a cache has to hold the path to the image file to
reload it.
> Display functions ask the cache (like CachePathRetImage) for the image
object.
>
> > But what will happen if after
> > requesting a freed image your system goes out of memory again?
>
> It will free older images and retry the memory request. If the cache is (all chaches are) empty, the the request really fails.
>
> There are usually many items in an application that are held in memory for time efficiency reasons and that could be freed if necessary. Typically
these
> things are ignored on todays 256+ MB virtual memory PCs. ut you didn't
ignore
> this when you did multimedia CDs for 16-64 MB PCs. I think you won't ever ignore it on systems with limited memory (embedded, pda, e-book) or
systems
> that mix gigantic objects (like 600 dpi truecolor scans) with normal
memory
> usage.
>
> > What if you can't free some images because they're on display?
>
> You can free them anyway. Being on the display doesn't mean that you need their info to redraw them. You could have a long HTML-like window where
you
> scroll up and down over many images. The most recently redrawn and cached and quick. The other are loaded and cached on demand.
>
> > Catching the OutOfMemory
> > and trying to recover from it can become pretty tricky. For these cases
I
> > think that the best is to use WeakReferences for the images, so we can reload them as needed but if there's few memory the system will free
some of
> > them. Of course this won't happen when the second (and inevitable) OutOfMemory occurs, but makes your algorithm clearer.
>
> This is exactly that kind of Java thinking that I think is dangerous. WeakReferences and the whole system built around them in Java are
extremely
> tricky and only solve a selfmade problem. If we follow Java paths then we will end where Java is. Bloated.

It's strange, because I think that making malloc catch an OutOfMemory and decide to drop some arbitrarily chosen objects and then retry the malloc is a tricky hack. It's the HOW not the WHY. WeakReferences exist in other OO languages, rather than Java (Eiffel and Smalltalk come to mind) and they model object references that can be freed if memory is too low. Just what our problem is.

> BTW there are other systems that use emergency memory pools (Perl) to be able to recover or to be at least able to output dying message in an OO environment gracefully.

There are other kinds of Error possible in Java, most of the time its a bad idea to try to catch them and continue.

> Start a Java Swing application within 20 MB memory limits. It used to just die without giving any any information about the reason. It will just stop working (or end in loop).

This is a problem of the bloated implementation of the Java VM and the Swing framework. Try to compile a C++ problem and link it with all libraries you can't find, and make sure to call at least one method of each inside a big initialization block before your main method. Java sucks because they have lots of interdependent libraries, not because it's the way it handles memory. If they designed the Swing properly it would be fast (look at Smalltalk GUIs, fast, tight (somewhat) and purely-object oriented) and tight, dynamic allocation whatsoever. There's a paper (IIRC named "Compiling Java to high-performance") talking about some specific changes to the Java compiler (mostly to simulate structs and such) to improve Java performance regarding numeric intensive applications. They give figures of 80% of Fortran speed.

> >     Here we are talking about naming conventions. There's no problem in
> > following Java naming conventions in D. Of course we won't follow the
> > library design, because we have better mechanisms for several idioms.
>
> I'm not quite sure that I know what you mean in detail.
> Could you start a comparision chart for these machanisms/idioms?
> It would be a good basis for library design.

I'm writing an article to illuminate such differences. The most important is the delegate feature in D, because it's fairly simple to use (i.e. no much typing when compared to Java) there's more incentive for library writers and programmers to offer higher-order algorithms:


list = list.filter(delegate bool(int n) {return n > 10;});

mutex.withDo(delegate void() {
    printf("I'm thread-safe!\r\n");
});

connection.withDo(delegate void() {
    connection.withStatementDo("SELECT * FROM FOO WHERE BAR = BAZ",
        delegate void(Statement stmt) {
            stmt.withResultSetDo(delegate void(ResultSet rs) {
                rs.doAll(&print);
            });
        }
    );
});


    The last two example uses the "withDo" idiom, common from Lisp (they use
"with_***_do" macros instead), to ensure that the resource is properly
initialized, the block executed, and then the resource is finalized
(something like RAII, but more general).
    Templates also give us many interesting ideas, allowing us to write more
generic code.

> --
> Helmut Leitner    leitner@hls.via.at
> Graz, Austria   www.hls-software.com


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 19/8/2003

Helmut Leitner wrote:

>>    That's perfect! There's no need to state inheritance hierarchy in the
>>class' name.

> In general: yes. But with respect to certain structural elements: no.
> 
> It's important to be able to focus e. g. all Error and Exception handling
> in a project. The only efficient way to do so is be text search for the
> words "Error" or "Exception". 

Searching for "throw" and "catch" should be enough


> Of course one could recover from OutOfMemory if one wants to. We do in the following example:

One can in C++, and in D, but in Java this might not work anyway. If the guys have decided that OutOfMemory means deth, so it probably does... :)

> It's a question of language, consistency and standards. We currently have neither. It seems that most contributors would rather borrow from Java.
> I think that D and Java are so different in philosophy that imitating
> Java language might even cripple D APIs.

There is a beginning of a coding standard, which is initiated by Walter and mimics Java - probably just because people are familiar with it.

-eye

In article <biguio$ki5$1@digitaldaemon.com>, Ilya Minkov wrote:
> Helmut Leitner wrote:
> 
>>>    That's perfect! There's no need to state inheritance hierarchy in the
>>>class' name.
> 
>> In general: yes. But with respect to certain structural elements: no.
>> 
>> It's important to be able to focus e. g. all Error and Exception handling in a project. The only efficient way to do so is be text search for the words "Error" or "Exception".
> 
> Searching for "throw" and "catch" should be enough

And, if you're searching for the exception classes' definitions, searching for Exception and Error should be enough, since they will derive from either of those classes anyway.

-Antti

Do you mean that we can search for, say, OutOfMemory by virtue of its inheritance relationship to, say, Error, as in

  class OutOfMemory
    : Error

then this is not really tenable. First, people declare inheritance in several ways

class OutOfMemory : Error

or

class OutOfMemory :
 Error

or (the correct way :-)

class OutOfMemory
  : Error

Of course any decent source search tool can easily handle that. However, what about the (extremely likely) case of a deep inheritance hierarchy (OT: exceptions are about the only place where deep inheritance hierarchies are appropriate IMAE)

class SystemXxxx
    : Error

class Win32Xxxx
    : SystemXxxx

class OutOfMemory
    : Win32Xxxx

class VirtualMemory
    : OutOfMemory

This may not be the most accurate anticipation of a future hierarchy, but
you can *guarantee* that there will be analogous ones. There are now several
problems to the
"nameless error/exception" plan.

 1. Your tool will have to be pretty smart to deduce up four levels that
VirtualMemory is an Error. Most people do, and will continue to do, use
grep.
 2. The names for SystemXxxx and Win32Xxxx are written thus because I can't
think of a decent name for them, other than SystemError and Win32Error. I
can't very well call them System and Win32, can I? And if we call do call
them SystemError and Win32Error - given that that's *exactly* what they
are - then isn't it inconsistent and confusing to use the non-appended names
OutOfMemory and VirtualMemory?

In any exception hierarchies, the vast bulk of the classes describe an action/event that is shared by several components, and experience in a multititude of manners. Of course, there are specific (leaf-node) exceptions to this, such as BadIndexException, which may very well be named just BadIndex. But IOException is a type we most certainly want in our exception hierarchy. If it does not have the appended Exception, what do we call it? IO? That is misleading. It is an IO exception, so should be called IOException. Calling a leaf node type InvalidFilePermissionsException may be over egging the pudding (although I don't actually agree that it is), but it is consistent with the names of non-leaf nodes which must, in general, comprise the "area" + "Exception"/"Error"

Of course, if I've misunderstood your intent, then I've just wasted a few thousand brain cells. ;)

Matthew

"Antti Sykäri" <jsykari@gamma.hut.fi> wrote in message news:slrnbkqak3.s51.jsykari@pulu.hut.fi...
> In article <biguio$ki5$1@digitaldaemon.com>, Ilya Minkov wrote:
> > Helmut Leitner wrote:
> >
> >>>    That's perfect! There's no need to state inheritance hierarchy in
the
> >>>class' name.
> >
> >> In general: yes. But with respect to certain structural elements: no.
> >>
> >> It's important to be able to focus e. g. all Error and Exception
handling
> >> in a project. The only efficient way to do so is be text search for the words "Error" or "Exception".
> >
> > Searching for "throw" and "catch" should be enough
>
> And, if you're searching for the exception classes' definitions, searching for Exception and Error should be enough, since they will derive from either of those classes anyway.
>
> -Antti
>

Thank goodness for people like Matthew Wilson, who can express things so well. I agree with this argument 156000%, but the best I could come up with until now has been "it's just better that way."

I am now officially changing my reason for voting for error/excpetion suffixes.

Thanks, Matt.

--Benji Smith

You are TOO generous by half!

I'm just a raggedy-brained f-wit most of the time. I just happened to hit a small bit of mental clarity at the same time as getting the hump with the debate. I decided in favour of polite, though comprehensive, explanation rather than any more of my unpopular curt retorts.

So Benji, maybe we can add you to the list of probably buyers of my putative D book, which takes the grand total to 18, IIRC. ;)


"Benji Smith" <dlanguage@xxagg.com> wrote in message news:bijf40$1hko$1@digitaldaemon.com...
> Thank goodness for people like Matthew Wilson, who can express things so
well. I
> agree with this argument 156000%, but the best I could come up with until
now
> has been "it's just better that way."
>
> I am now officially changing my reason for voting for error/excpetion
suffixes.
>
> Thanks, Matt.
>
> --Benji Smith
>
>

Matthew Wilson wrote:
> So Benji, maybe we can add you to the list of probably buyers of my putative D book, which takes the grand total to 18, IIRC. ;)

You can add me to the list. Adds up to 19. :-)

BTW congratulations to your excellent performance comparision articles.

--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

> You can add me to the list. Adds up to 19. :-)

You guys .... <G>

Helmut, I've locked your offer of reviewer in the vault, so don't think you can escape. (Believe me, being a book reviewer isn't all fun-and-games. Having been on both sides it's certainly easier to be a reviewer, but it's no cake walk!)

> BTW congratulations to your excellent performance comparision articles.

Many thanks. :)

btw, if anyone wants to see (i) the updates with .NET SDK 1.1 and/or (ii)
the next installments in the series (some heavy container and comms
studies), you need to email the WDN editor
(http://windevnet.com/wdn/contact/) and let them know.

In article <bijavc$1bnf$1@digitaldaemon.com>, Matthew Wilson wrote: [snip]
> Of course any decent source search tool can easily handle that. However, what about the (extremely likely) case of a deep inheritance hierarchy (OT: exceptions are about the only place where deep inheritance hierarchies are appropriate IMAE)
> 
> class SystemXxxx
>     : Error
> 
> class Win32Xxxx
>     : SystemXxxx
> 
> class OutOfMemory
>     : Win32Xxxx
> 
> class VirtualMemory
>     : OutOfMemory

Perhaps I should have stated my suggestion more clearly.

I am not at all of the opinion that we should drop Exception and Error from those names where they naturally belong. In fact, this inheritance hierarchy would be a perfect example of using names Exception and Error precisely where they fit well and not using them where they don't:

(Forgive me for switching the places of OutOfMemory and VirtualMemoryError -- I believe the hypothetical hierarchy looks more realistic this way)

class SystemError : Error

class Win32Error : SystemError

class VirtualMemoryError : Win32Error

class OutOfMemory : VirtualMemoryError
class GeneralProtectionFault : VirtualMemoryError
class IllegalOperation : VirtualMemoryError

I agree that the non-leaf nodes of the inheritance hierarchy tend to describe errors of a general domain, and the proper name for them is "area" + "Exception"/"Error".

But the leaf nodes often mean just one particular error condition, in which case it has a name that already indicates what kind of a creature it is. IndexOutOfBounds? An exception. StackOverflow? An error. ObjectFactoryBuilder? Uh, neither. But that's obvious. And so on. Besides, there wouldn't be a lot of them, not at least in the standard library, at least if it wouldn't grow too bloated. You could probably memorize them if you wanted.

And no one said that XXXException wouldn't be a valid leaf exception class -- certainly it is if there is no better name. AuthenticationException, for example, is a perfectly good name for a class if you don't know the particular reason (or don't care about differentiating them) for an exception that an authentication module just throwed.

The fundamental point is: I would prefer catching DivisionByZero instead of DivisionByZeroException and StackOverflow instead of StackOverflowError, because in these particular cases stating the obvious -- that we're talking about an exception or an error -- seems just too redundant. It feels as if you named application's main function mainFunction() instead of main() or its arguments (String[] argumentStrings) instead of (String[] args). Or used the horrid CSomeClass prefix or any sort of hungarian notation.

(Which is, of course, a matter of personal opinion.)

But I agree that maybe, just maybe, a little extra typing would be better than having to think whether to put in the extra Exception or not. Consistency tends to be a good thing. After all, I'm programming in a statically typed language where you need to keep stating the obvious, and I even consider that a good thing. Besides, most IDEs and editors have auto-completion for us lazy typers...

>  1. Your tool will have to be pretty smart to deduce up four levels that
> VirtualMemory is an Error. Most people do, and will continue to do, use
> grep.

This is a stunningly valid argument.

Even though I think that non-leaf exception classes should mostly be
called XXXError or YYYException, and so the leaf nodes would have to
derive from a class that has one of those endings, and therefore
"grep -B1 Error *.d" would indeed find most if not all of them. But this
would not be 100% bullet-proof, firstly because you really don't *have*
to specify the base class in the same or the next line to make it
compile, secondly because that switch works only in GNU grep, and
thirdly because 90% of people would not bother to use or learn that
switch, let alone have an opportunity to use a more sophisticated source
browsing system.

How often do you want to grep for all exceptions? (It's been ages since I've used them in a real project; lately I've been working with systems that don't support exceptions, so I don't really remember what to answer myself.)

-Antti