@everybody, Does anybody oppose me adding to code to top-level, lower-cased packages "int", "num", and "str"? What about top-level packages "Int", "UInt", "Str", or "Num"? Do other type systems use these top-level packages?
@Reini, You always have good and useful ideas, but you always come across as so worried. Fear not! It looks like my use of type information is philosophically aligned with what you do with types in cperl and B::CC. When I said I wanted to use the type stash in a way 'entirely different' from the fields pragma, I meant it was orthogonal, not opposed, to the pragma. My only requirement for a type stash's package is that it have a class method called c_blocks_init_cleanup. This function is called while constructing the initialization and cleanup code for variables of the indicated type. I believe that this implementation detail is orthogonal to your use of types and can coexist in the packages used by cperl and B::CC. Still, I'm uncertain that I want to use top-level package names for types. B::CC works with "int" and "num", and "str" is planned. cperl also implements Int, UInt, Num, and Str. For C::Blocks, the upper- and lower-cased variants would effectively be identical. Supporting these as types for C::Blocks will be easy for me to implement and does not (IMHO) grab too much top-level namespace. However, I plan on having all of the standard C types, including bit-count names from stdint.h such as uint16_t, int32_t, intptr_t, etc. Should all of these be top-level packages? I believe not, and this is why I had proposed using the C:: prefix (and the suffice _t) for my types. Could cperl support these additional types? There is one implementation detail in which our approaches differ. For a number of types, I have implemented c_blocks_init_cleanup in a generic way in a base class, and use inheritance to let my type classes tweak behavior. You mention here <http://perl11.org/cperl/perltypes.html#coretypes> that cperl's coretypes have an empty @ISA. While I could revise the handful of coretypes that you support to avoid inheritance (direct glob assignment would work, for example), is there any chance that you'll extend this set of types to the many other C integer types? That would be doable, but annoying. Thanks! David On Wed, Oct 26, 2016 at 10:39 AM, Reini Urban <reini.ur...@gmail.com> wrote: > > > On Oct 26, 2016, at 4:31 PM, David Mertens <dcmertens.p...@gmail.com> > wrote: > > > > Hello everyone, > > > > I am writing a keyword hook, C::Blocks. I have realized that my hook > could be made more powerful if I could indicate optional type information > for variables. > > > > Question 1: Perl has support for declaring a variable's type, but it is > intended to be used with the fields pragma. I get the impression that this > is rarely used and I want to use it for something entirely different. Can > anybody see a problem with this? > > yes, I have a problem with that. > no, types are not only used for the field pragma. > cperl has proper type support and any "modern perl” needs type support. > B::CC, the optimizing compiler, has coretype support even in perl5. > Every lexical has the optional type stash and better signature > implementations set that also, > so that perl5 can finally look like a modern perl as perl6 or cperl, but > not like Moose/Mouse/Moo/… or even worse, > old-style fields. > > > Question 2: I want to keep the class names for the type system > relatively short. Can anyone think of problems for names such as: > > > > C::double_t > > C::int_t > > C::IV_t > > See the cperl coretype names. If they are the same, use it, otherwise use > your own variants. > > > Reini Urban > rur...@cpan.org > -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
