[#4745] Win32: Ruby & APR; build problems for Ruby Subversion SWIG bindings — Erik Huelsmann <ehuels@...>

Having taken upon me the task to provide a Windows build for

24 messages 2005/04/20
[#4746] Re: Win32: Ruby & APR; build problems for Ruby Subversion SWIG bindings — Austin Ziegler <halostatue@...> 2005/04/20

On 4/20/05, Erik Huelsmann <ehuels@gmail.com> wrote:

[#4747] Re: Win32: Ruby & APR; build problems for Ruby Subversion SWIG bindings — Erik Huelsmann <ehuels@...> 2005/04/20

Hi Austin,

[#4762] Re: Win32: Ruby & APR; build problems for Ruby Subversion SWIG bindings — nobu.nokada@... 2005/04/24

Hi,

[#4783] Re: Win32: Ruby & APR; build problems for Ruby Subversion SWIG bindings — Erik Huelsmann <ehuels@...> 2005/04/25

On 4/24/05, nobu.nokada@softhome.net <nobu.nokada@softhome.net> wrote:

[#4787] Re: Win32: Ruby & APR; build problems for Ruby Subversion SWIG bindings — nobu.nokada@... 2005/04/25

Hi,

[#4794] Re: Win32: Ruby & APR; build problems for Ruby Subversion SWIG bindings — Erik Huelsmann <ehuels@...> 2005/04/25

> > > Ruby is just using AC_TYPE_UID_T. So, using typedef for them,

[#4751] Illegal regexp causes segfault — Andrew Walrond <andrew@...>

irb(main):058:0> a = /\[([^]]*)\]/

13 messages 2005/04/22

Re: want_object? - possible?

From: "David A. Black" <dblack@...>
Date: 2005-04-14 23:50:06 UTC
List: ruby-core #4717
Hi --

On Fri, 15 Apr 2005, Mark Hubbart wrote:

> On 3/24/05, David A. Black <dblack@wobblini.net> wrote:
>> Hi --
>>
>> On Fri, 25 Mar 2005, Daniel Berger wrote:
>>
>>> Keep in mind that some of the contexts mentioned there
>>> do not apply to Ruby, e.g. lvalue subs.  In fact, most
>>> may not.  But, if there were some way for a method to
>>> detect whether it's part of a chain in advance, that
>>> might be useful.
>>
>> I don't think there is a way, logically, within the basic
>> message-receiver-response model.  The idea of an object knowing what
>> is going to happen after it finishes responding to the message seems,
>> to me, to be part of a pretty deeply different design.  At that point,
>> also, you're not really chaining method calls; you're using
>> method-chaining syntax to execute something that's really not linear
>> from left to right.  At that point, the a.b.c syntax starts to obscure
>> what's really happening, rather than revealing it, I think.
>
> There are occasions where a nice uses_return_value? would help:
>
> module Enumerable
>  def zip(*others)
>    if block_given?
>      if uses_return_value?
>        # build a new array using the block, return it
>      else
>        # yield each set of elements, don't build array.
>      end
>    [...]
>
> and using it with method chaining:
>
> (1..26).zip('a'..'z'){|n,c| n.to_s + c}.map{|v| #do stuff here}
>
> Looks good to me!

I still don't like the look-ahead aspect of this.  It seems to me to
be a quantum leap from block_given? -- in the sense that the presence
or absence of the block is part of the semantics of this method call,
whereas the whole "what happens *after* we return from this method
call?" is part of the semantics of the next method call (or lack
thereof).

Consider this (purely illustrative) example:

   module Array
     def something
       if subsequently_flattened?
         push(1)
       else
         push(2)
       end
       self
     end
   end

   a = []
   a.something.flatten  #  a == [1]
   a.something          #  a == [1,2]

It is no step at all in kind, and only a small step in degree, from
the question "Is what I return going to be used in a chain?" to the
question "Is what I return going to be chained to the 'flatten'
method?" (or any other specific method).  It strikes me as a whole
type of knowledge that is not the business of the method that's
currently executing.


David

-- 
David A. Black
dblack@wobblini.net

In This Thread