Front page | perl.perl5.porters |
Postings from November 2011
Zefram via RT wrote:
> This part now vaguely makes some sense. It appears that you're after
> an importing mechanism that doesn't load a module if the package to be
> imported from is already defined. We have "use base" which performs such
> soft loading and then adds the target package to @ISA. You're asking
> for a keyword that does something like
>
> BEGIN {
> Module::Runtime::use_package_optimistically("PACKAGE");
> "PACKAGE"->import(ARGS...);
> }
>
> This is achievable, but it doesn't make sense as part of "use".
> Strict module loading is the essence of "use".
---
More precisely, strict loading is the essence of "use BAREWORD". As "use
EXPR" is not defined in the language.
As mentioned before, "BAREWORD" and "EXPR" are syntactically and
semantically different.
"use", only, uses the "require BAREWORD|VERSION" form of "require", but
does NOT use it's "require EXPR" form.
I'm proposing that in line with Perl's "use Module" syntax, where
"Module" *must* be a BAREWORD, that
"use EXPR"
also be ADDED to the language with acknowledgement that it is
processed at runtime:
BEGIN {
defined(Module = eval EXPR) || eval "require EXPR"
}
Then "use" and "require" would become more parallel functions, with
focus on "Class/Package", and "File" (@Inc relative), respectively.
Both would retain existing BAREWORD and VERSION semantics.
Both would check for their objects' preexistence and only continue
with inclusion on 'non-existence' (by object-specific test):
"use" checks object's 'define' already being in memory.
"require" checks existence of the name in in @INC.
"use" would pass an eval'd non-loaded object as BAREWORD to "require"
(i.e. continue to include it's object) and when "require" is
done, do optional class imports.
"require" retain current function of no conversion on expressions
passed directly to it.
> This part makes no sense. I entirely fail to see how allowing
> non-constant module names in "use" would address the issue you've
> described. I think you've just misunderstood things and this is a
> red herring.
---
See above.
>> Now, you can tell me that perl isn't really an OO language,
>
> Your issue also seems to be unrelated to object orientation.
---
See above.
>> having the classes be interdependent on each other depending on where
>> they are located to each other, doesn't seem to fit the idea of them
>> being 'independent' of each other.
>
> The usual approach, as previously mentioned, is to put each class and
> exporting package in its own module (file). Then they're independent.
>
>> You define a code file as a module. Thats your arbitrary definition.
>
> It's the definition being used by Perl's documentation. Picking a
> different definition, and then interpreting the documentation according
> to your definition, is a fairly obvious recipe for confusion.
---
I seek a more general definition that doesn't require extra code
restricting Perl's functionality and lowers conceptual complexity
regarding the different semantics allowed by "require" over "use".
> You need to try editing your messages down after you've written the
> first draft. The signal/noise ratio is awfully low.
---
That was a 3rd-4th draft, as was this. But I had a more
clear definition of what suited my target audience. Hopefully
I didn't err in the opposite direction.
Thread Previous
|
Thread Next