Removal of Pseudo-Hashes: what happens to compile-time checks
Johannes Plass
developers (time to raise your hands, guys !)
pseudo-hashes offer two major and purely
functional advantages:
- a consistent and solid framework for object oriented
programming via the "base" and "fields" pragmas.
- compile-time checking when accessing attributes
of typed pseudo-hashes.
Now the plan is to remove pseudo-hashes for performance
related reasons. Keeping the functionality of the "base" and
"fields" pragmas is part of the migration
plan but I haven't heard so far what will happen
to the compile-time checking of typed pseudo-hashes.
For those not familiar with this feature just have
a look at the following code:
package Galaxy;
use strict;
use fields
(
"name",
);
#===============================================
sub new {
my $class = shift;
#===============================================
my Galaxy $self = bless [], ref($class)||$class;
$self->{xxx} = "Milky Way";
}
Put this code into a file test.pl and do a 'perl test.pl'
and you immediately get the compile-time error:
No such pseudo-hash field "xxx" in variable $self of type Galaxy at
test2.pl line 15.
When implementing large perl projects this compile-time checking
is extremely valuable not only when subclassed objects access
attributes of their superclasses. In perl it's also the safest
way to access foreign objects like in the following code
package Universe;
use strict;
use Galaxy;
#===============================================
sub doSomethingWithGalaxy {
my Universe $self = shift;
my Galaxy $galaxy = shift;
#===============================================
if ($galaxy->{xxx} eq "Milky Way") {
# foo
}
else {
# bar
}
}
In this example, like in the one above, "using" the Universe package
immediately results in the compile-time error
No such pseudo-hash fields "xxx" in ...
The consequence of this feature is a rule for minimizing the
maintainance overhead when dealing with large object trees in perl:
- don't use methods to access/set object attributes
since you only get run-time checking on the existence
of the methods.
Otherwise you'll find yourself in the middle of a
maintainance and quality assurance nightmare as
soon as you have to change your classes.
- use typed pseudo-hashes since you get compile-time
checking for every object attribute you access/set.
Even complex changes of your objects can be done
quickly and safely since compile-time checking
catches most issues.
This rule is contrary to the standard OOP textbooks but
this is perl and perl is different.
Certainly this rule is my personal 'best way' to
attack large projects in perl. But I assume there are pretty
many application developers who do it in a similar way
and for which the possible loss of the described compile-time
checking is rather critical.
To summarize:
For me perl's pseudo-hashes in conjunction with
the 'base' and 'fields' pragmas and
the compile-time checking on typed pseudo-hashes
are the most consistent approach to do larger-scale
object-oriented programming in perl.
So *PLEASE* do everything possible to keep the
compile-time checking alive when removing the
pseudo-hashes in the next version of perl.
And if this is not possible then *PLEASE DON'T* remove them.
--
Johannes Plass <johanne...@web.de>
Arthur Bergman
On lördag, augusti 10, 2002, at 11:06 , Johannes Plass wrote:
>
> For me and probably for a lot of other application
> developers (time to raise your hands, guys !)
> pseudo-hashes offer two major and purely
> functional advantages:
>
> - a consistent and solid framework for object oriented
> programming via the "base" and "fields" pragmas.
> - compile-time checking when accessing attributes
> of typed pseudo-hashes.
>
> Now the plan is to remove pseudo-hashes for performance
> related reasons. Keeping the functionality of the "base" and
> "fields" pragmas is part of the migration
> plan but I haven't heard so far what will happen
> to the compile-time checking of typed pseudo-hashes.
>
types.pm is going to my replacement for this, it will also allow nested
type and alot more.
Arthur
ps, new types.pm coming up soon with subroutine arguments!
Johannes Plass
> types.pm is going to my replacement for this, it will also allow nested
> type and alot more.
Well, perhaps this is a misunderstanding, so please allow to restate my
point:
When writing larger-scale, object-oriented software in perl
it always happens that the code is changing often and drastically.
And it is in this situation where it would be great to have some
module that does compile-time checking when accessing attributes
of typed objects and when calling methods of typed objects.
The following example demonstrates the desired features by
means of a yet non-existent module called 'checking':
A. First declare a sample class
package Galaxy;
use fields qw(name);
sub setName { ... }
B. Now use the class with compile-time checking of attributes
package main;
use checking qw(attributes); # this is the mystical module
# that does the compile-time checking
use Universe;
use Galaxy;
my Galaxy $galaxy = Universe->getGalaxyByName("MilkyWay");
$galaxy->{Name} = "NewMilkyWay";
^^^^ BOOM AT COMPILE-TIME: no such attribute <Name>
C. Now use the class with compile-time checking of methods
package main;
use checking qw(methods); # this is the mystical module
# that does the compile-time checking
use Universe;
use Galaxy;
my Galaxy $galaxy = Universe->getGalaxyByName("MilkyWay");
$galaxy->SetName("NewMilkyWay");
^^^^^^^ BOOM AT COMPILE-TIME: no such method <SetName>
This is really all that is needed. Not more, not less.
Less checking throws you into a maintainance nightmare: whenever you
change your objects you must somehow find and fix changed method
calls and accessed attributes in all your code. Doing this error free
is impossible if you have to rely on run-time checking for method calls
and no checking at all for attribute access.
Arthur, do you think something like that can be done ?
I fear I'm lacking the expertise in the perl internals to
create such a module myself, but if you think it can be done
and if no one of the perl gurus volunteers I'm willing
to jump into the cold water ....
To summarize:
Having a 'checking' module as shown above would be a great help
when coding and maintaining larger perl projects.
And it thereby would surely push perl more into the direction of a
serious programming language suitable for larger projects.
--
Johannes Plass <johanne...@web.de>
Yitzchak Scott-Thoennes
I thought the plan was to make fields.pm use the new restricted hashes.
(Johannes, these were added in 5.8.0 mostly to pave the way to remove
pseudo-hashes. See the new Hash::Util)
Michael G Schwern
> On Mon, 12 Aug 2002 15:13:06 +0200, art...@contiller.se wrote:
> >types.pm is going to my replacement for this, it will also allow nested
> >type and alot more.
>
> I thought the plan was to make fields.pm use the new restricted hashes.
It should use whatever makes fields.pm work as close to 5.8.0 as possible.
Right now, all we've got is restricted hashes which emulates everything but
the compile-time key checking. If types can emulate fields.pm better, and
not drag on performance, then we should use that.
--
Michael G. Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One
I don't get it. Must be art.
Michael G Schwern
> Now the plan is to remove pseudo-hashes for performance
> related reasons.
Performance was just the straw that broke the camel's back. It's actually
to remove a heap of overcomplicated code from the internals of Perl, to free
up the meaning of typed lexicals, and to throw out a feature that doesn't
play well with Perl's OO model (ie. no multiple-inheritance support).
See http://dev.perl.org/rfc/241.pod for a full explanation.
> Keeping the functionality of the "base" and
> "fields" pragmas is part of the migration
> plan but I haven't heard so far what will happen
> to the compile-time checking of typed pseudo-hashes.
We'll do our best to preserve it, somehow.
--
Michael G. Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One
Thanks, applied. Or, ??????k@???????K^U
as we Bulgarian EBCDIC users like to say.
-- Jarkko Hietaniemi in <2002013007...@alpha.hut.fi>