headers
TRANS | 10 Aug 03:39
Picon
Gravatar

Fwd: New RCR: Tighter Support for Symbolic Parameters

Long time no post!

---------- Forwarded message ----------
From:  <>
Date: Aug 9, 2005 9:18 PM
Subject: New RCR: Tighter Support for Symbolic Parameters
To: transfire <at> gmail.com

A new RCR has been submitted by transami:

RCR 310: Tighter Support for Symbolic Parameters

You can view this RCR at:

http://www.rcrchive.net/rcr/show/310
-------- End Forwarded message --------

Hi All,

Just created this RCR. The need for it came up in Facets, so I went
ahead and put it out there.

At the end of the RCR I say that my two proposals are the only ones
possible. Upon thinking about that some more I determined there are
two things I _don't_ like about them. 1) multiple flags don't look so
hot, and 2) using a parameter to guild functionality  hampers
reusability (ie. subclassing).

So then another possibility occured to me, what if the : notation
represented a delayed reaction?
(Continue reading)

Permalink | Reply | 0 comments |
headers
TRANS | 21 Apr 15:44
Picon
Gravatar

The Atomicity of Facets

Okay, so I banding my head against a wall here. I need advice. Ruby
Facets is designed to give the programmer fine grained control over
the extension methods he/she may require. Yet I'm not sure if I should
be "extreme" about it or not. The atomicity works very well in many
cases. But there are some areas were it is not so clear cut. Take the
time extensions to Numeric:

  def microseconds
    self.to_f / 1000000.0
  end
  alias :microsecond :microseconds

  def milliseconds
    self.to_f / 1000.0
  end
  alias :millisecond :milliseconds

  def seconds
    self
  end
  alias :second :seconds

  def minutes
    self * 60
  end
  alias :minute :minutes

etc. Do I put each of those into separate files? If I do I will have a
separate "mass require" that requires them all at once. But I have to
wonder, is there really any advantage to having them separate in the
(Continue reading)

Permalink | Reply | 5 comments |
headers
TRANS | 14 Apr 05:03
Picon
Gravatar

Here's a strange one: class locals as class methods

So I find myself once again creating some classes that have state. And
I have two options, either the class defines a class method for the
info, or in a superclass I define a method that will set that info to
a class var.

  # Example A
  class Thing1 < TheseThings
    def self.mystate ; "what have you" ;  end
  end

or

  # Example B
  class Thing1 < TheseThings
    mystate "what have you"
  end

The first is rather, well, ugly. Although it makes sense, it's what
one does at the instance level all the time (i.e. defining methods to
fit the interface). The second is nice and dsl-ish, but requires a
method to be predefined in TheseThings, despite the simplicity.

Now everytime I go about this I find myself writing:

  # Example C
  class Thing1 < TheseThings
    mystate = "what have you"
  end

b/c that just seem natural, and then I go back and "fix" it. So
(Continue reading)

Permalink | Reply | 0 comments |
headers
TRANS | 11 Apr 02:03
Picon
Gravatar

Module Macros

So I took Georges original code and (thus far) have touched it up to
create this "macros" for modules. What do others think?

# = Module Macros
#
# A macro construction for creating dynamic mixins.
#
# == Example
#
#   module Mixin
#     macro { |options| %{
#       def hello
#         puts 'Hello from #{options[:name]}'
#       end
#     } }
#   end
#
#   class MyClass
#     include Mixin, :name => 'tml'
#   end
#
#   m = MyClass.new
#   m.hello -> 'Hello from tml'
#
# == Arthur
# 
#   Based on code by George Moschovitis <gm <at> navel.gr>
#
class Module
(Continue reading)

Permalink | Reply | 0 comments |
headers
TRANS | 9 Apr 01:50
Picon
Gravatar

Dynamic Parameterized Mixins

George Moschovitis, author of Nitro and Og sent me some code for doing
parameterized mixins as follows:

  # = Dynamic include
  #
  # Allows you to include dyanamic mixins.
  #
  # * George Moschovitis  <gm <at> navel.gr>
  # (c) 2004-2005 Navel, all rights reserved.
  # $Id: dynamic_include.rb 338 2005-03-31 16:26:10Z gmosx $

  class Module
    alias_method :__include_without_options__, :include
    def include(*args)
      options = args.last.is_a?(Hash) ? args.pop : {}
      for mod in args
        if mod.respond_to?(:append_dynamic_features)
          mod.append_dynamic_features(self, options)
        end
      end
      __include_without_options__(*args)
    end
    alias_method :dynamic_include, :include
  end

Here's the example of its use:

  module Mixin
    def self.append_dynamic_features(base, options)
 	base.class_eval %{
(Continue reading)

Permalink | Reply | 7 comments |
headers
TRANS | 1 Mar 19:36
Picon
Gravatar

[AOP] Namespaces rather then just a local namespace

I've been thinking some more about the local namespace idea for
cut-based AOP. For those interested but haven't heard this mentioned
before, the idea is to have a namespace akin to private/protected, but
that is local to the class scope and invisible outside of it. So for
example:

  class C
    def x ; 1 ; end
  end

  class D
    def y ; x ; end
    local
    def x ; 2 ; end
  end

  d = D.new
  d.y  #=> 2
  d.x  #=> 1

This allows for AOP aspect modules to be fully reusable without
worrying about possible name clashes.

The other day it occured to me that it might be better to have more a
more flexible, user definable system using namepaces that are
accessable like methods.

  class D
    def y ; myspace.x ; end
    namespace myspace
(Continue reading)

Permalink | Reply | 0 comments |
headers
TRANS | 2 Feb 20:01
Picon
Gravatar

On the problem of "self-shimmying" to Module methods

On the problem of "self-shimmying" to module methods. Take this Cut as example:

  class C
    def name ; "Suby" ; end
    def inform ; "Here she comes!" ; end
  end

  cut A < C
    def inform
      MyAspect.announce( self )
    end

    module MyAspect
      def self.announce( self )                       #problem!
        "[ANN] #{self.name}" + super          #and problem!
      end
    end

  end

First, we would like to avoid explicitly having to passing self, for
convenience (and possibly for no longer having reusable mixins.
Irregardless of the fact that self cannot actually be passed this way
--a syntax error is thrown. There's still the problem of super's
redirection: Which hierarchy should the method follow when #super is
called? The module's? Or the cut's class's? This junction gives
insight into to why the atom of AOP is a Cut. More percisely, a
Cross-Cut.

But recall that even without the module, #super presents a difficulty
(Continue reading)

Permalink | Reply | 3 comments |
headers
TRANS | 2 Feb 08:00
Picon
Gravatar

Parameter Trend and Flags

Noticing a trend. Perhaps it is obvious, but

   def ameth(*args,**keys,&blk)
      # ...
   end

Notice that *args tells Ruby to expect an array, ** a hash, and & a
block. Pretty clever. I think we should add one more, a :: for
symbols.

   def ameth(*args,**keys,::flags,&blk)

Then symbol flags could be collected from the front of the parameters list.

  new:big "Hello World"

  args = [ "Hello Word" ]  
  flags = [ :big ]

Now, an array of symbols is what I'll call a Tuple. Which I think
could be written:

  :a:b:c

So if we really wished, as in fact it is, ::flags requests a Tuple,
not exactly an Array. But again neither is a Hash.[1]

T

[1] Now if only I could get &&blks :-) [2]
(Continue reading)

Permalink | Reply | 16 comments |
headers
TRANS | 2 Feb 07:43
Picon
Gravatar

Are two better than one?

I came up with a very interesting way to have a dual sort of
inheritence in a class --two selves, that is to say, two self.

  class Object
    def self.new(*args, &blk)
      @self = self
    end
  end

Since @self is assignable, it plays the part of a "role". The key to
this is simply in the fact that @self looks so much like 'self' and we
are thus habituated and will think of it as self, which it also
defaults too. So in effect, to always use @self in ones calls instead
of the default self leads to a completely dynamic "soul" in an object.

I suggest this be a better rule of thumb. The true self of an object
lies in the totality of it's instance variables. What then of this
other keyword 'self' Is it perhaps but a distraction? Or is a static
self also necessary?

T
Permalink | Reply | 0 comments |
headers
TRANS | 1 Feb 00:56
Picon
Gravatar

Usenet Mirrors of this list

Is 'gmane.comp.lang.ruby.musing' considered a real Newsgroup? Is it a
Usenet newsgroup?

I'm curious, b/c I was wondering if Google Groups could also mirror
the list --I like their interface (for the most part).

Thanks,
T
Permalink | Reply | 2 comments |
headers
Florian Groß | 26 Jan 17:22
Picon

Unit-testing based contracts

Moin.

I've recently been thinking about typing and come to the conclusion that 
unit testing is a perfect fit for implementing type contracts.

The attached library implements exactly that as well as some candy in 
the form of run-time method signature checks.

All this is not yet final and subject to change, but I figured that this 
list might be a valuable resource for getting early feedback. I'd be 
especially interested in suggestions for improving the interface of it 
so that it can be used easier and in suggestions for future directions.

I've already thought about providing support for multi method 
dispatching and invariants, but I'm not yet sure how to implement those.

Unit tests are still missing, but documentation already ought to be of 
reasonable quality, though it still misses a few complete examples. Let 
me provide one here instead:

irb(main):001:0> class ListContract < Contract 

irb(main):002:1>   provides :size do 

irb(main):003:2*     assert(@object.size >= 0, "#size should never be 
negative.")
irb(main):004:2>   end 

irb(main):005:1>
(Continue reading)

Permalink | Reply | 6 comments |

Gmane