[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Blocks, serailizing, and "configure, don't integrate"

Hugh Sasse

11/22/2004 3:06:00 PM

6 Answers

Robert Klemme

11/22/2004 3:16:00 PM

0


Hmmm,

as the writing and reading instance is the same, what about writing a
class that acts as a block proxy and that recreates the code after loading
the way you described but with a single difference: the code is encryptet.
Of course, with reasonable effort it's still easy to play foul - but at
least you can make sure that noone changes serialized code accidentally or
on purpose and then simply loads it.

Another thing in the direction of your mini-language could be this: you
write a class that describes the callback relationship. Callbacks
typically just forward an event to somewhere (or you can enforce this
rule). Then the callbacks are generated from the connection information
(source instance, source event, target instance, target method to invoke).

Just my 0.02EUR...

Kind regards

robert

Hugh Sasse

11/22/2004 4:09:00 PM

0

leon breedt

11/22/2004 8:49:00 PM

0

Hi Hugh,

I don't see much benefit to be gained from serializing the callback
procs themselves. I would rather go for the approach where you
serialize an identifier associated with the callback.

A good example of what I'm getting at is Glade. Its a UI description
format (XML) for Gtk/Gnome. When you load in the Glade file, you get
back a container that holds all the Gtk UI object instances. The Glade
file only stores the callback name (they call it signals); in your
code you then dispatch to the appropriate method based on that name.

The Ruby Glade bindings can be found together with the Ruby Gnome2 bindings:

http://ruby-gnome2.sourc...

ptkwt

11/22/2004 9:03:00 PM

0

In article <Pine.GSO.4.60.0411221431520.23251@brains.eng.cse.dmu.ac.uk>,
Hugh Sasse Staff Elec Eng <hgs@dmu.ac.uk> wrote:
>The second part of this is:
>
>I find myself wanting blocks to be real objects before they become
>procs. I'm trying to think this out but it feels like grasping wet
>soap -- I can't quite get a hold on the idea. I'm thinking
>something like this:
>
> We can't marshal procs because they carry external state.
> We can't marshal blocks or lambdas for the same reason.
>
> When you marshal an object you give it enough information to be
> re-constructed, possibly minus a few features (things that don't get
> dumped).
>
> Can we marshal a proto-block, that when loaded in a context
> causes a block to come into being in that context, without
> opening ourselves up to a full eval? Then we could do something
> like Block.new(Marshal.load(...)) to get a block, to pass to
> proc or whatever. Possibilities that this would have include
> warnings on the code within the block before/after it is
> serialized/restored, and formatting as some AST so it is less
> prone to casual hacking when serialized [caveats about security
> through obscurity apply].
>
>I'm thinking that simplifying this would enable greater utility, as
>is true for all abstractions, as well as aid debugging.
>

Have you looked at nodewrap?
http://rubystuff.org...

I also sometimes think that it would be useful to have a Block class and
that code blocks would be instances of Block... but I suspect that would
be too big of a change to Ruby at this point.

Anyway, if there were a Block class it might work something like:

block = { puts "my code block" }
puts block.class #=> Block
puts block.to_s #=> "{ puts \"my code block\"}"
p = block.to_proc

def useblock(&b) #could take Block object and convert to proc
b.call
end

#Then useblock could be called in two ways:

useblock block
useblock { puts "use this block" }


But then, maybe there wouldn't be enough difference between a Block and a
Proc to make this kind of change worthwhile. Also, while in this simple
case you could easily marshal 'block', other cases where a block needed to
carry around more context (references to in-scope variables, etc. ) would
still seem to be problematic unless you were to say that Block objects do
not carry around any context, but that they 'inherit' the context in which
they are loaded (the problem then being that if the Block refers to some
variables that it expects to have in scope but aren't in the scope where
the marshalled Block is loaded).

Phil

Hugh Sasse

11/22/2004 11:00:00 PM

0

Hugh Sasse

11/22/2004 11:02:00 PM

0