Re: question

> Samuele Pedroni <[email protected]>:
> >
> > Hi.
> >
> > Why
> [snip]
> > vs.
> >     def noWidget(self):
> >        try:
> >          return isinstance(self.widget,DummyWidget)
> >        except AttributeError:
> >          return 1
>
> Kneejerk reaction against type checking (evil, evil ;)

gone a bit overboard <wink>.

>
> The current versions allows for any sort of signature-equivalent
> dummies, not just the specific one in question. Not very useful,

but the point of the null/dummy object pattern is to offer a null/dummy
implementation of some protocol, on the other hand having a dummy recognition
protocol does not work very well because the objects the dummy object is the
dummy version
often cannot  implement it and one should go the exception way.

For example this an example of a "typical" null object (a null compiled re-like
object):

class FailRegexp:
    def match(self,text):
        return None

    def search(self,text,pos):
        return None

The only advantage of DummyWidget over None:

is that it can be distinguished from None and

dummyWidget.attr returns something (a DummyWidget)

instead of failing, but I don't know how often this can be really exploited in
the code without except contorsions. I should check that.

> perhaps, but all other things being equal, I'd rather avoid type
> checking... :]

but here is harmless and on the other hand

100000 times the "except" fond approach cost 8s on my machine,
100000 times the evil approach cost <1s on my machine

and the exception abuse is not IMO very readable.

> On the other hand, this dummy system may not be the best way of
> handling the situation at all -- I didn't really give it long and hard
> thought between I implemented it. Perhaps there could be some other
> way of doing this stuff... The idea was to avoid checking for dummies
> in all the get/set methods. It seems that some has snuck back, at
> least in the getters, to avoid returning None where a string or number
> is expected, for instance. Not ideal...
>

Yes, this stuff need some rethinking.

For the moment I think it allows to write:

   isDummy(self.widget.parent)

although in the code is written:

  try:
    self.widget.parent.isDummy()
  except AttributeError:

or something like that.

> (BTW: There is a function in Util that does this dummy-checking job,
> so there is actually duplicated functionality here, with this method.)
>



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390