Re: Selective exporting of properties/methods
> While thinking Eiffel-ish thoughts the other day, I began to wonder if
> Perl6's classes could go beyond the simple private/public/protected
> scheme by optionally allowing for a property or method to only be
> accessed by a certain set of classes.
Many times when I've used OO languages I've wished for something like this.
What I've often wanted would be standard method that is called before every
subroutine call. If that method returns false then the method that was
called is not called. A standard set of security information is passed in.
That could get kind of expensive so the security method is only called if
the class is specifically set to use it. Something like this:
class Foo::Bar {
use Class::Security::Method 'checker';
sub checker (%meta) {
if (some_security_check())
{return 1}
return 0;
}
}
-Miko
Re: Selective exporting of properties/methods
On Sunday, May 12, 2002, at 02:18 PM, Miko O'Sullivan wrote:
>> While thinking Eiffel-ish thoughts the other day, I began to wonder if
>> Perl6's classes could go beyond the simple private/public/protected
>> scheme by optionally allowing for a property or method to only be
>> accessed by a certain set of classes.
>
> Many times when I've used OO languages I've wished for something like
> this.
> What I've often wanted would be standard method that is called before
> every
> subroutine call. If that method returns false then the method that was
> called is not called.
I think maybe what you're looking for is another Eiffel/Sather-ism. I
know Eiffel at least has both pre and post-conditions that look
something like this(it's been a while, so if this isn't quite right):
class
ACCOUNT
creation
make_with_balance
feature { BANK }
balance: INTEGER
make_with_balance(initial_balance: INTEGER) is
require
initial_balance >= 0
do
balance := initial_balance
ensure
balance >= 0
end
end
I too have thought this might be useful in Perl6. Perhaps...
class Account {
my INT $balance;
method new(INT $initial_balance //= 0) {
REQUIRE { $initial_balance >= 0; }
$.balance = $initial_balance;
ENSURE { $.balance >= 0; }
}
}
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
From: "David Whipp" <[EMAIL PROTECTED]> > It it too much to ask, of the creator of a tied array, to implement > their code in such a way that *reading* an element of that array > does not have significant side-effects? Actually, I think that *is* a significant imposition. The whole point of tied arrays ( and hashes, scalars, etc) is that they act like arrays but internally do whatever they want. But could we go back a step? Could somebody explain why we need lookaheads, or perhaps what exactly a "lookahead" is in this context? Part of the current interface for tied arrays is that they know how long they are. It seems like it would be a relatively simply algorithm to say "if there are still elements left in the array then populate the loop variable with the next element and run the block. Else, leave the variables as they are, run the LAST block." -Miko
Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)
In a message dated Sun, 12 May 2002, Miko O'Sullivan writes: > From: "David Whipp" <[EMAIL PROTECTED]> > > It it too much to ask, of the creator of a tied array, to implement > > their code in such a way that *reading* an element of that array > > does not have significant side-effects? > > Actually, I think that *is* a significant imposition. The whole point of > tied arrays ( and hashes, scalars, etc) is that they act like arrays but > internally do whatever they want. This reminds me of my first experience writing a kernel handler for the /proc filesystem. I was just learning how it worked, and made the handler increment an internal variable and print it every time the file was read. I was surprised to see the following behavior, when I cat'd the file several times: $ cat /proc/test Counter is 0 $ cat /proc/test Counter is 3 $ cat /proc/test Counter is 9 $ cat /proc/test Counter is 13 $ cat /proc/test Counter is 16 (Note the extra newline after 9.) This is absolutely correct behavior--if you know how the standard C library implements file I/O, you can see what's going on (hint: I used %d in the format to sprintf). But it's wildly unintuitive. But this is just how things are. If the act of reading a particular data structure has side effects, especially side effects that cause the semantics of the data structure to alter, code which expects ordinary semantics, where reading is idempotent, will behave unexpectedly. Trey
