undefine

R

Robert Klemme

Claus Spitzer said:
I concur.
It's probably easier if you think of a variable as just a pointer to
an object, not as the objects themselves.

Maybe it's easier because it's more accurate? ;-)

robert

 
R

Robert Klemme

Claus Spitzer said:
well yes... It's just part of the procedural-->OO shift that everyone
needs to go through at some point.

In fact this has nothing to do with procedural vs. OO. The way how
variables (locations) and values are related is completely orthogonal to the
nature of the language (procedural or OO).

Regards

robert

 
T

tony summerfelt

In fact this has nothing to do with procedural vs. OO. The way how
variables (locations) and values are related is completely orthogonal to the
nature of the language (procedural or OO).

in my particular case i'm thinking black box approach. i don't want
the variable to 'exist' any more.

i don't know if that's how it's thought of in perl, but when i
undef($x), $x is no longer there for me to use unless i assign it
something, and i can test that it isn't with:

if ! defined($x) # do something.

as long as ruby 'acts' the same way, it's all i need.
 
C

Christoph

tony summerfelt wrote:
....
in my particular case i'm thinking black box approach. i don't want
the variable to 'exist' any more.

i don't know if that's how it's thought of in perl, but when i
undef($x), $x is no longer there for me to use unless i assign it
something, and i can test that it isn't with:

if ! defined($x) # do something.

as long as ruby 'acts' the same way, it's all i need.

I am aware of this kind of functionality for
instance and class variables - for local or
global variables such methods, afaik (I am not
really sure!!!) don't exist.
I see no problems with a removal method
for global variables but we are probably better
off without removal methods for local variables.


---
class A
@x = 1
@@x = 1
$x = 1
x = 1
remove_instance_variable :mad:x
remove_class_variable :mad:@x
begin
remove_gobal_variable :$x
rescue => mes
puts mes
end

begin
remove_local_variable :x
rescue => mes
puts mes
end
end
 
R

Robert Klemme

Claus Spitzer said:
Again, this is where it's useful to consider the OO approach and think
of variables as just the symbols you use to reference to objects. If
the symbol you're using is not assigned to any object (a.k.a. it
points to nil) then it it undefined.

I know I'm picky, but

1) You don't "assign a symbol to an object". If at all it's the other way
round: you assign an object to a symbol. But I'd rather say "you make the
variable point to an instance". The symbol is just the representation of
the memory location that holds a reference to some instance.

2) 'nil' is in fact a valid instance. It has methods that can be invoked
safely:
=> 4

This is different from Java where you get a NullPointerException if you
try to invoke any methods on 'null'.

I think you wanted to say the right thing but it was a bit ill formulated
IMHO.

Kind regards

robert
 
R

Robert Klemme

Christoph said:
tony summerfelt wrote:
...

I am aware of this kind of functionality for
instance and class variables - for local or
global variables such methods, afaik (I am not
really sure!!!) don't exist.
I see no problems with a removal method
for global variables but we are probably better
off without removal methods for local variables.

What do you gain by undefining instance variables? If you access it via
@foo it'll be nil anyway.

Regards

robert
 
B

Ben Giddings

tony said:
in my particular case i'm thinking black box approach. i don't want
the variable to 'exist' any more.

i don't know if that's how it's thought of in perl, but when i
undef($x), $x is no longer there for me to use unless i assign it
something, and i can test that it isn't with:

if ! defined($x) # do something.

as long as ruby 'acts' the same way, it's all i need.

I think the best way to get the behaviour you want is to use a hash.
Instead of assigning the value to a variable, you just assign the value
to a hash key.

$h = Hash.new

def test_key(sym)
if $h.has_key?(sym)
...
else
...
end
end

test_key:)foo)

$h[:foo] = "Bar"

test_key:)foo)

$h.delete:)foo)

test_key:)foo)

Now if you don't use .has_key? and you just try to access the hash
entry, you'll just get 'nil' back (by default at least). If you want to
have an exception raised instead, that's doable too.

Ben
 
G

gabriele renzi

il Tue, 15 Jun 2004 00:17:55 +0900, Ben Giddings
I think the best way to get the behaviour you want is to use a hash.
Instead of assigning the value to a variable, you just assign the value
to a hash key.

$h = Hash.new

def test_key(sym)
if $h.has_key?(sym)
...
else
...
end
end

hey, accesing globals from a method is ugly, just use a singleton :)

H=Hash.new

def H.test_key sym
if has_key? sym
...
else
...
end
end
 
T

tony summerfelt

Again, this is where it's useful to consider the OO approach and think
of variables as just the symbols you use to reference to objects. If
the symbol you're using is not assigned to any object (a.k.a. it
points to nil) then it it undefined.

i just need the variable to 'not exist' however it's thought about (by
me or others :) isn't a concern.

i'm willing to bet that perl coders are having a harder time with ruby
than coming from another language :) i'm so used to 'thinking in perl'
that unlearning some of the perl magic is taking some effort...
 
T

tony summerfelt

I think the best way to get the behaviour you want is to use a hash.

it seems to be more work (and lines of code) than it needs to be for
just one variable.

i was surprised that ruby didn't have a simple undefine function. and
for the oo'ness of it, it could look like x.undefine. no more x :)
 
T

tony summerfelt

Why is this?

i refer to my earlier message about a blackbox approach...

for my own purposes, and those of anybody looking at the code, if they
can count on the variable not existing (after being 'undefined')
that's all that matters.

when i'm past the relative newbie stage and start digging into the
internals of ruby, i will want to know the 'why'.
 
M

Michael Campbell

i refer to my earlier message about a blackbox approach...

Well, you say you want it to no longer exist because you want it to no
longer exist. I'm not sure I see why, though I might not be reading
closely enough.

What about the logic of your code or design depends on the 'existence'
of a variable? What problem is it you're trying to solve with this
approach?
 
C

Christoph

Robert Klemme wrote:
....
What do you gain by undefining instance variables? If you access it via
@foo it'll be nil anyway.


I did not advocate removing, a.k.a. undefining,
instance variable, I was just pointing out that
these removal methods exists - but since you asked:

Removing an instance or class variable after
its usefulness expired (a typical example are
auxiliary instance variable used in nontrivial
initializers distributed over several auxiliary
methods) is IMO a good practice mainly for
esthetical reasons (akin to the well established
practice of always initialing instance variable
before using them) - on occasion you might even
catch an error this way. Another reason is that
unused instance variable take up unnecessary
memory space.

It seems harder to me to make a similar compelling
stylistic (and memory) case for the existence of
removal methods for class variables and especially
for global variables, and removal method for local
variables make no sense at all.

/Christoph
 
T

tony summerfelt

What about the logic of your code or design depends on the 'existence'
of a variable? What problem is it you're trying to solve with this
approach?

just makes the code shorter. here's an excerpt of a log trimming
program in perl (for the format that binkd generates) ('@' precedes
arrays in perl):

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);
}

this goes through each line in the log file.
if the log line contains a date stamp, it's processed and written to
an archive file if it meets the criteria, and the next line in the
file is read.

some lines are blank but i want written to the archive file for
cosmetic purposes. i COULD rewrite the perl code to NOT use
defined/undef (tim toadie and all that). but i don't have to.

when i ported it to ruby i found the equivalent ruby code longer.
maybe when i know the language a lot better it won't be and i'll find
a shorter way of doing it...
 
S

Sean O'Dell

What about the logic of your code or design depends on the 'existence'
of a variable? What problem is it you're trying to solve with this
approach?

just makes the code shorter. here's an excerpt of a log trimming
program in perl (for the format that binkd generates) ('@' precedes
arrays in perl):

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);
}

this goes through each line in the log file.
if the log line contains a date stamp, it's processed and written to
an archive file if it meets the criteria, and the next line in the
file is read.

Don't check for defined, check for nil. It's virtually the same thing, unless
there's a chance that Delta_DHMS returns nil as a real return value.

Sean O'Dell
 
J

Josh Huber

tony summerfelt said:
{
# 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);
}

Can't you just use "=nil" to achive the same thing?

i.e. something like:

diff = Delta_DHMS(binkdate, today) if /(\[\d+\])/
print trimmed $_ if diff[0] < ARGV[1] && diff
next if diff
print trimmed $_ if ! /(\[\d+\])/
diff = nil

(just using the fact that 'nil' is false)
 
M

Mark Hubbart

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.

cheers,
Mark
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

Forum statistics

Threads
473,764
Messages
2,569,566
Members
45,041
Latest member
RomeoFarnh

Latest Threads

Top