"Sean O'Dell" <sean@celsoft.com> schrieb im Newsbeitrag
news:200406141559.01604.sean@celsoft.com...
> > while(<binkd>)
> > {
> > # date parsing code was here
> > @diff=Delta_DHMS(@binkdate,@today) if /(\[\d+\])/;
> > print $trimmed $_ if $diff[0] < $ARGV[1] && defined(@diff);
> > next if defined(@diff);
> > print $trimmed $_ if ! /(\[\d+\])/;
> > undef(@diff);
> > }
>
> testing whether diff is defined won't work in ruby anyway. Any time
you
> have an expression like this:
>
> foo = 23 if expression
>
> foo ends up being automagically defined anyway. After running that
> code, if expression is false, foo == nil.
>
> So, as Sean says, it would probably be better to use nil, unless
> Delta_DHMS might return nil itself.
Oh! Which brings to mind something really neat I figured out awhile
ago. If
Delta_DHMS really can return nil as a valid value, try re-writing the
code
like this:
{
# date parsing code was here
@diff=Delta_DHMS(@binkdate,@today) if /(\[\d+\])/;
print $trimmed $_ if $diff[0] < $ARGV[1] && @diff != :undefined;
next if @diff != :undefined;
print $trimmed $_ if ! /(\[\d+\])/; @diff = :undefined;
}
Initialize @diff = :undefined in your class initialize method.
:undefined
will be a Ruby symbol that gets created on its first use. From there on
out,
just set @diff to :undefined whenever you need to "undefine" it.
To me this seems simpler:
while ( diff = /(\[\d+\])/ && Delta_DHMS(@binkdate, @today) )
print ...
end
robert
···
On Monday 14 June 2004 15:47, Mark Hubbart wrote:
> On Jun 14, 2004, at 2:58 PM, tony summerfelt wrote:
I looked at the BLOCK structure that is the C representation of the binding
object, but I only learned two things. One, I can't really tell without
spending a lot more time poking around how dyna_vars really binds a
symbolically named internal variable to an object and two, you probably could
create internal variable objects to represent them. I don't see why not.
Probably it would work best through the Binding object itself. Matz, or
someone who understands how the BLOCK structure is used well enough, could
add methods to Binding to add and remove variables, and if a Variable class
were written to point into the variable it represents in a BLOCK structure,
it could probably also return objects to represent the variable.
Sean O'Dell
···
On Tuesday 15 June 2004 15:09, Mark Hubbart wrote:
On Jun 15, 2004, at 1:38 PM, Sean O'Dell wrote:
> On Tuesday 15 June 2004 11:45, Mark Hubbart wrote:
>> On Jun 15, 2004, at 10:19 AM, tony summerfelt wrote:
>>> On Tue, 15 Jun 2004 14:55:05 +0900, you wrote:
>>>>> I did not advocate removing, a.k.a. undefining,
>>>>> instance variable,
>>>
>>> it would be a local variable i'd be undefining, probably not an
>>> instance variable (although i'd like that option also)
>>
>> I think the whole point here is that it isn't Ruby-ish to rely on a
>> variable being defined or not. Ruby wassn't built to do things in that
>> way; a couple examples in this thread show how variables are
>> automagically defined when code is parsed. They aren't defined at
>> runtime, they are defined at eval time. So basically, If you are
>> translating code from Perl that undefines local variables, you will
>> have to find a different way of doing it, due to the way Ruby was
>> designed. I doubt that this is likely to change, because it's part of
>> how Ruby was designed.
>
> Actually, Matz could probably very easily expose variables as objects
> themselves to be manipulated like anything else in Ruby. I don't think
> because he hasn't done it yet constitutes a "design decision" as much
> as
> "something he didn't do." It's not impossible, in other words, it's
> just a
> feature that doesn't exist yet.
Yes, I agree, it is possible that Matz could implement that. I think
though that it would be less of an addition than a conversion. For
example:
foo = 23 unless true
p defined? foo
Will print "local-variable". The code foo in which foo was assigned to
was not run, so the '=' operator was never really applied to it. So if
there was a Variable class, and the '=' operator was its method, that
method would not be called in the above code. Because of this, I
strongly suspect the above would print "nil" if there was a Variable
class.
I may not be understanding it fully (I'm self-taught, there are many
gaps in my knowledge) but it *looks* like a design decision to me, and
'variables as objects' couldn't be implemented without a non-trivial
change to the way the language works. But I could easily be wrong
