logical |ˈläjikəl|
adjective
of or according to the rules of logic or formal argument : a logical
impossibility.
• characterized by clear, sound reasoning : the information is
displayed in a simple and logical fashion.
• (of an action, development, decision, etc.) natural or sensible
given the circumstances : it is a logical progression from the job
before.
• capable of clear rational thinking : her logical mind.
DERIVATIVES
logically |-ik(ə)lē| |ˈlɑdʒək(ə)li| adverb : such a situation is
logically impossible.
logistics |ləˈjistiks; lō-|
plural noun [treated as sing. or pl. ]
the detailed coordination of a complex operation involving many
people, facilities, or supplies : the logistics and costs of a
vaccination campaign.
• Military the organization of moving, housing, and supplying troops
and equipment.
• the commercial activity of transporting goods to customers : [as
modifier ] Germany's largest beverage logistics organization.
logistic |ləˈjistik; lō-|
adjective
of or relating to logistics : logistic problems.
DERIVATIVES
logistically |-tik(ə)lē| |ˈləˈdʒɪst1k(ə)li| adverb
So can't see how "logistically false" is meaningful without a lot of stretching.
···
On Sun, Apr 6, 2008 at 5:05 AM, Robert Klemme <shortcutter@googlemail.com> wrote:
On 05.04.2008 23:33, Todd Benson wrote:
> > > > a FalseClass object or a NilClass object will be logistically false.
> > Note though that "logistical" != "logical" - two quite different pairs of shoes.
> That's being a little nitpicky.
Absolutely!
> I think either word works in this
> case, but I understand what you meant
If by "works" you mean "can be understood" then, yes. If you say that the
word can be placed there from a language point of view, also yes. I do
believe though that "logistically" is semantically misplaced here. :-))
(See the hash default case which flushes this out.)
David
--
Rails training from David A. Black and Ruby Power and Light:
ADVANCING WITH RAILS April 14-17 New York City
INTRO TO RAILS June 9-12 Berlin
ADVANCING WITH RAILS June 16-19 Berlin
See http://www.rubypal.com for details and updates!
I'm not a stickler for concrete semantics in written conversation, so...
Yes, it is a stretch, but makes perfect sense to me. Maybe I didn't
word the sentence correctly. I was referring to _how_ you tackle the
weirdness (the logistics), not the _what_ (the inherent logic).
Todd
···
On Sun, Apr 6, 2008 at 10:13 AM, Rick DeNatale <rick.denatale@gmail.com> wrote:
On Sun, Apr 6, 2008 at 5:05 AM, Robert Klemme > <shortcutter@googlemail.com> wrote:
> On 05.04.2008 23:33, Todd Benson wrote:
As long as we're being pedantic.
logical |ˈläjikəl|
adjective
of or according to the rules of logic or formal argument : a logical
impossibility.
• characterized by clear, sound reasoning : the information is
displayed in a simple and logical fashion.
• (of an action, development, decision, etc.) natural or sensible
given the circumstances : it is a logical progression from the job
before.
• capable of clear rational thinking : her logical mind.
DERIVATIVES
logically |-ik(ə)lē| |ˈlɑdʒək(ə)li| adverb : such a situation is
logically impossible.
logistics |ləˈjistiks; lō-|
plural noun [treated as sing. or pl. ]
the detailed coordination of a complex operation involving many
people, facilities, or supplies : the logistics and costs of a
vaccination campaign.
• Military the organization of moving, housing, and supplying troops
and equipment.
• the commercial activity of transporting goods to customers : [as
modifier ] Germany's largest beverage logistics organization.
logistic |ləˈjistik; lō-|
adjective
of or relating to logistics : logistic problems.
DERIVATIVES
logistically |-tik(ə)lē| |ˈləˈdʒɪst1k(ə)li| adverb
So can't see how "logistically false" is meaningful without a lot of stretching.
> Furthermore things are simple
>
> (1) lval ||= rval is lval = lval || rval
>
I think you mean:
lval || lval = rval
(See the hash default case which flushes this out.)
Wow David, as they say "A little knowledge is a dangerous thing", well
as I said ignorants like me teaching nonsense
Thx for correcting me David.
Cheers
Robert
···
On Sat, Apr 5, 2008 at 2:40 PM, David A. Black <dblack@rubypal.com> wrote:
On Sat, 5 Apr 2008, Robert Dober wrote:
David
--
Rails training from David A. Black and Ruby Power and Light:
ADVANCING WITH RAILS April 14-17 New York City
INTRO TO RAILS June 9-12 Berlin
ADVANCING WITH RAILS June 16-19 Berlin
See http://www.rubypal.com for details and updates!
I also thought so, but, according to "The ruby programming language", it's an
exception. It states that, if the left hand of var ||= something is not nil or
false, no assignment is performed and, if the left hand is an array element or
attribute, the setter method is not called.
Stefano+
···
On Saturday 05 April 2008, Brian Adkins wrote:
On Apr 5, 8:40 am, "David A. Black" <dbl...@rubypal.com> wrote:
> Hi --
>
> On Sat, 5 Apr 2008, Robert Dober wrote:
> > Furthermore things are simple
> >
> > (1) lval ||= rval is lval = lval || rval
>
> I think you mean:
>
> lval || lval = rval
Huh?
My understanding has always been that x ||= y is shorthand for x = x
>> y just as x += y is shorthand for x = x + y. That also seems to be
the understanding of the "Programming Ruby" text (p. 125 of the
latest). In other words, an assignment will take place even if it's
superfluous.
My understanding has always been that x ||= y is shorthand for x = x
>> y just as x += y is shorthand for x = x + y. That also seems to be
the understanding of the "Programming Ruby" text (p. 125 of the
latest). In other words, an assignment will take place even if it's
superfluous.
Strictly speaking, it isn't shorthand for either, since there are
cases where the expansion will fail but ||= won't because x isn't
initialized. However, discounting that, the expansion is:
x || x = y
The only time this matters is with hashes that have default values. In
every other case, as far as I know, x = x || y also describes what's
happening. But the expansion which describes *every* case is x || x =
y.
On Apr 5, 8:40 am, "David A. Black" <dbl...@rubypal.com> wrote:
On Sat, 5 Apr 2008, Robert Dober wrote:
--
Rails training from David A. Black and Ruby Power and Light:
ADVANCING WITH RAILS April 14-17 New York City
INTRO TO RAILS June 9-12 Berlin
ADVANCING WITH RAILS June 16-19 Berlin
See http://www.rubypal.com for details and updates!
The only time this matters is with hashes that have default values. In
every other case, as far as I know, x = x || y also describes what's
happening. But the expansion which describes *every* case is x || x =
y.
One other case (a very similar one) in which it matters is this:
class C
def x; @x || 5; end
def x=(v); puts "assigning @x=#{v}"; @x = v; end
end
c = C.new
c.x ||= 3 # no effect
p c.x # 5
c.x = 2 # assigning @x=2
p c.x # 2
···
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Interesting - nice blog post. That is surprising, inconsistent and
unfortunate
···
On Apr 5, 12:08 pm, "David A. Black" <dbl...@rubypal.com> wrote:
>> I think you mean:
>> lval || lval = rval
> Huh?
> My understanding has always been that x ||= y is shorthand for x = x
> >> y just as x += y is shorthand for x = x + y. That also seems to be
> the understanding of the "Programming Ruby" text (p. 125 of the
> latest). In other words, an assignment will take place even if it's
> superfluous.
Strictly speaking, it isn't shorthand for either, since there are
cases where the expansion will fail but ||= won't because x isn't
initialized. However, discounting that, the expansion is:
x || x = y
The only time this matters is with hashes that have default values. In
every other case, as far as I know, x = x || y also describes what's
happening. But the expansion which describes *every* case is x || x =
y.
Hmm I am not sure I believe you rushed your example a little bit
c.x = c.x || a
and
c.x || c.x = a
seem to me having the same effect.
I only came up with a perverse example to show the difference
class C
count = 0
def x; true end
define_method :x= do |_|
count += 1 @x = count
end
end
c = C.new
c.x || c.x = 42
p c
c.x = c.x || 42
p c
c.x ||= 42
p c
Cheers
Robert
···
On Sat, Apr 5, 2008 at 7:57 PM, Joel VanderWerf <vjoel@path.berkeley.edu> wrote:
David A. Black wrote:
> The only time this matters is with hashes that have default values. In
> every other case, as far as I know, x = x || y also describes what's
> happening. But the expansion which describes *every* case is x || x =
> y.
>
One other case (a very similar one) in which it matters is this:
class C
def x; @x || 5; end
def x=(v); puts "assigning @x=#{v}"; @x = v; end
end
c = C.new
c.x ||= 3 # no effect
p c.x # 5
c.x = 2 # assigning @x=2
p c.x # 2
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
The only time this matters is with hashes that have default values. In
every other case, as far as I know, x = x || y also describes what's
happening. But the expansion which describes *every* case is x || x =
y.
One other case (a very similar one) in which it matters is this:
class C
def x; @x || 5; end
def x=(v); puts "assigning @x=#{v}"; @x = v; end
end
c = C.new
c.x ||= 3 # no effect
p c.x # 5
c.x = 2 # assigning @x=2
p c.x # 2
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Hmm I am not sure I believe you rushed your example a little bit
c.x = c.x || a
and
c.x || c.x = a
seem to me having the same effect.
On Sat, Apr 5, 2008 at 7:57 PM, Joel VanderWerf <vjoel@path.berkeley.edu> wrote:
--
Rails training from David A. Black and Ruby Power and Light:
ADVANCING WITH RAILS April 14-17 New York City
INTRO TO RAILS June 9-12 Berlin
ADVANCING WITH RAILS June 16-19 Berlin
See http://www.rubypal.com for details and updates!
>
> > David A. Black wrote:
> >
> >
> >
> > > The only time this matters is with hashes that have default values. In
> > > every other case, as far as I know, x = x || y also describes what's
> > > happening. But the expansion which describes *every* case is x || x =
> > > y.
> > >
> > >
> >
> > One other case (a very similar one) in which it matters is this:
> >
> > class C
> > def x; @x || 5; end
> > def x=(v); puts "assigning @x=#{v}"; @x = v; end
> > end
> >
> > c = C.new
> > c.x ||= 3 # no effect
> > p c.x # 5
> > c.x = 2 # assigning @x=2
> > p c.x # 2
> >
> > --
> > vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
> >
> >
> >
> Hmm I am not sure I believe you rushed your example a little bit
>
> c.x = c.x || a
> and
> c.x || c.x = a
> seem to me having the same effect.
>
that is true but that point was difficult to see, and I preferred an
example which shows the difference from the "normal" object interface
although my code is of course perverted.
···
On Sat, Apr 5, 2008 at 10:02 PM, David A. Black <dblack@rubypal.com> wrote:
On Sun, 6 Apr 2008, Robert Dober wrote:
> On Sat, Apr 5, 2008 at 7:57 PM, Joel VanderWerf <vjoel@path.berkeley.edu> > wrote:
=> nil
irb(main):020:0> c.x = c.x || 1 # c.x = 5 || 1 => c.x = 5
assigning @x=5
=> 5
irb(main):021:0> c.instance_eval { @x }
=> 5
David
--
Rails training from David A. Black and Ruby Power and Light:
ADVANCING WITH RAILS April 14-17 New York City
INTRO TO RAILS June 9-12 Berlin
ADVANCING WITH RAILS June 16-19 Berlin
See http://www.rubypal.com for details and updates!
> Hi --
>
>
>
>
> >
> > > David A. Black wrote:
> > >
> > >
> > >
> > > > The only time this matters is with hashes that have default values. In
> > > > every other case, as far as I know, x = x || y also describes what's
> > > > happening. But the expansion which describes *every* case is x || x =
> > > > y.
> > > >
> > > >
> > >
> > > One other case (a very similar one) in which it matters is this:
> > >
> > > class C
> > > def x; @x || 5; end
> > > def x=(v); puts "assigning @x=#{v}"; @x = v; end
> > > end
> > >
> > > c = C.new
> > > c.x ||= 3 # no effect
> > > p c.x # 5
> > > c.x = 2 # assigning @x=2
> > > p c.x # 2
> > >
> > > --
> > > vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
> > >
> > >
> > >
> > Hmm I am not sure I believe you rushed your example a little bit
> >
> > c.x = c.x || a
> > and
> > c.x || c.x = a
> > seem to me having the same effect.
> >
>
> I don't think so:
>
> irb(main):017:0> c = C.new
> => #<C:0x87d0c>
> irb(main):018:0> c.x || c.x = 1 # 5 || c.x = 1 => 5
> => 5
> irb(main):019:0> c.instance_eval { @x }
that is true but that point was difficult to see, and I preferred an
example which shows the difference from the "normal" object interface
although my code is of course perverted.
and one cannot see the problem through the object interface either
In an attempt to make things clear enough I will take Joel's code again:
class << C = Class::new
def x; @x || 5 end
def get_x; @x end
def x= v; @x=v end
end
Hurray I guess I finally got it.
Thx for the enlightenment.
Cheers
Robert
···
On Sat, Apr 5, 2008 at 10:39 PM, Robert Dober <robert.dober@gmail.com> wrote:
On Sat, Apr 5, 2008 at 10:02 PM, David A. Black <dblack@rubypal.com> wrote:
> On Sun, 6 Apr 2008, Robert Dober wrote:
> > On Sat, Apr 5, 2008 at 7:57 PM, Joel VanderWerf <vjoel@path.berkeley.edu> > > wrote:
> => nil
> irb(main):020:0> c.x = c.x || 1 # c.x = 5 || 1 => c.x = 5
> assigning @x=5
> => 5
> irb(main):021:0> c.instance_eval { @x }
> => 5
>
>
>
>
> David
>
> --
> Rails training from David A. Black and Ruby Power and Light:
> ADVANCING WITH RAILS April 14-17 New York City
> INTRO TO RAILS June 9-12 Berlin
> ADVANCING WITH RAILS June 16-19 Berlin
> See http://www.rubypal.com for details and updates!
>
>
