On Oct-24, Leopold Toetsch wrote: > Steve Fink wrote: > > > >... If not, then just > >renaming it to Undef seems best. > > I had a closer look at it. Just renaming doesn't: PerlUndef is derived > from PerlInt, which provides major funtionality for it. > > If this syllable "Perl" is really a problem, I will reorganize them > again i a more hierarchical way, all perl classes on top of basic classes.
Well, it definitely bothers me, but maybe I'm just being anal retentive. Maybe this is the right time to ask another question I've been wondering about: is there anything perl-specific about PerlInt? PerlNum? Although if we're going to change PerlInt to Int (or just make a new Int base class that PerlInt would inherit from), then we should probably handle the question of how many bits these integers should have, and possibly create a couple of PMCs -- Int32, Int64, IntAtLeast32, NativeInt, UnboundedInt, IntAsBigAsYourHead, etc. Dan, do you have any design guidance to kick in here? What Parrot Int/Num PMCs do we need, and how should PerlInt relate to them? > But, as this is again a major patch I'd prefer to do it after 0.0.9, a > long with PMC/Buffer unification and variable/value separation, as both > steps will change the whole classes subdir drastically again. Fair enough. Although it looks like this release is still going to take some time to stabilize; there are still an uncomfortable number of warnings and GC bugs.
