On Thu, Aug 31, 2000 at 05:15:34PM -0700, Nathan Wiger wrote:
> First off, nice additions to the RFC.
Thanks. :)
> > Listed below are constructor alternatives. If a sub is chosen (as in sub
> > PREPARE {}) it will suffer from the disadvantage of potentially causing
> > problems with current Perl modules.
>
> I don't really think this is a valid concern. We can have p52p6 warn
> them, and all other Perl stuff (tie's STORE/FETCH, Perl's DESTROY, etc)
> are already done by ALLCAPS subs, just like global vars are $ALLCAPS.
You don't consider warnings from an otherwise working module a problem? I
do. It's an issue, and should be mentioned.
> Besides, what would be the alternative, BEGIN{} - like blocks?
Such blocks are put forth as an alternative:
> =item sub PREPARE {} or PREPARE {}
> I think these should just be subs, that way the user can call them at will
> as well. It also makes the implementation easier, just call the
> appropriate sub if it exists.
Being able to call these as normal methods may be desirable, or it may not
be. Personally, I will likely never call $spot->PREPARE, just as I never
call tied(%ixhash)->STORE("foo" => "bar"). If the module is intended to
have such things explicit methods should be provided, preferably lowercase
ones. That is not to say PREPARE (or whatever is chosen) should not be a
sub, I'm just questioning the practice of calling them directly.
> > If an appropriate constructor is not provided a fatal exception should be
> > raised when the syntax is used.
>
> Naw, I don't think we should go this route. If it's not a valid imported
> package, then the statement should die. But not defining a constructor
> should only yield a warning with -w:
>
> No implicit constructor defined by package Dog at line 47.
>
> At the very most.
So the object would be left undefined? That means this code:
my Dog $spot;
... intervening space ...
$spot->collar("studded");
emits a warning when there's no Dog->$METHOD, and then promptly dies when
you try to call a method on an undef object. The two constructs could be
quite a distance apart. I would rather have a fatal error at the source,
not the symptom.
> > This definition would probably be best provided through a pragma:
> >
> > use constructor qw(new);
>
> I also don't think we should do this. There's nothing more special about
> CREATE/PREPARE/NEW than DESTROY, STORE, or FETCH. We should provide what
> we think is a good name (and perhaps some alternatives), and let Larry
> decide.
Which is what I'm doing. I'm providing alternatives, including one
where the module author is allowed to name the implicit constructor. :)
> I'm very much against allowing people to tweak absolutely everything.
> There are minimal gains for marked losses in consistent, readable,
> maintainable code. See this link for a rant on how this can go really
> bad really quickly:
Sure, taken to the extreme, anything can be bad. There is more than a
little ugly Perl code out there (*gasp* blasphemer!) because some
programmers take certain features and idioms to the extreme. The same can
be said of any language.
However, consider existing tied classes, for example IO::File; it must
provide duplicate methods, lowercase for users, uppercase for the tied
interface. Would it really be less consistent or readable if, say, the
getline() method was able to be called when a user said either <$fh>, or
$fh->getline?
I'd say do both; provide some default method, and provide a way to specify
it when it makes sense.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
