in reply to Re^2: RFC: Win32::API API (names)
in thread RFC: Win32::API API

tye:

For the default thing, I was thinking along the lines of leaving the setting to "on", but only load Math::Int64 on demand. In other words, I was hoping to *not* load it until someone actually defined an API using 'q'. But that would likely overcomplicate things.

An alternative suggestion: If Math::Int64 is loaded and you're on a perl without quad support, *then* set the default to yes. Does that sound a bit more reasonable?

Update: Ever since my eye trouble, I notice myself missing things. On re-reading, I notice that you already suggested my alternative proposal. (Note: Don't get a retinal tear. They suck. Six months later, and my left eye *still* looks like I'm looking through a snow-globe.)

...roboticus

When your only tool is a hammer, all problems look like your thumb.

Replies are listed 'Best First'.
Re^4: RFC: Win32::API API (names)
by bulk88 (Priest) on Aug 18, 2012 at 15:09 UTC

    An alternative suggestion: If Math::Int64 is loaded and you're on a perl without quad support, *then* set the default to yes. Does that sound a bit more reasonable?

    Is probing ::VERSION or %INC the really right way to do things and changing your behavior based on what PMs are already in the process really a good idea?

    What if module A is loaded by main::, which uses Win32::API internally, loads Math::Int64 and uses the quads as Math::Int64 objects, then module B is loaded by main::, which uses Win32::API internally, does not load Math::Int64, and uses quads as 8 byte strings, now module B will fatally error since it didn't pass a Math::Int64 to Win32::API and instead passed a 8 byte string quad, because of the global probing of what modules are already loaded into the process.

    One solution to this problem in a non-Perl setting I saw was, to create a root "global settings" object, and then the main object is generated from a root global settings object. Each module/Library creates usually 1 global settings object for itself, but this way the global settings are library specific, not really global to the process. I dont know what to think about this solution. caller probing for the caller's stash and maintain a "global" settings DB for each caller's stash, or caller peeking in Perl is too unreliable and unprofessional?
[reply]

      Can't you just inspect the argument passed to you, check if it's a string, a native 64-bit, a native double, or an Math::Int64 object, and process it accordingly?

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?
[reply]
        I've decided to do that where possible based on your suggestion. But it can't work if the data direction is from C to Perl (return value of a C function, @_ value coming into a Perl callback from C). If a programmer is very lazy, and very smart, he can avoid turning on Math::Int64 support explicitly and just pass MI64 Objs and get away with it in some careful places.

        The other idea in this thread some people said, I think was to totally remove Quads on 32 bit Perls as 8 byte SV PV string support and if you say Quad on 32 bit Perl, you've said Math::Int64, no exceptions. 8 byte SV PV string support is not portable at all currently. On x64 the 8 byte packed int64 as a scalar string will become garbage to the C function. If you really want 64 bit ints as 8 byte strings, you can type pun it to a "char *" and remember to pad it out at your own risk. Any opinions on removing int 64s as 8 byte strings on 32 bit Perl feature and tell the user to C type pun to char * if they dont want to use Math::Int64?
[reply]

      bulk88:

      I see what you mean. The action-at-a-distance thing can be a problem.

      ...roboticus

      When your only tool is a hammer, all problems look like your thumb.

[reply]

In Section Seekers of Perl Wisdom