> i'd really like something like this for ruby (off the top of my head):
> class quit_button < button
> def initalize
> button_text("quit")
> self.show
> placeongrid()
> # you get the idea
> end
> def button_text(t)
> quit_text=t
> end
> def click
> app.cleanup
> end
> end
Inheritance just for the purpose to add callbacks/configuration
already proved to be wrong a long time ago. The only framework which
tried this was self, but as self is OO without classes it's not
comparable.
From the length of your example you should see where the problem is.
Can you expand on this a little? I find myself "borrowing" paradigms
and styles from one language/platform/pattern/etc. to the next as I
play with them, and would love to hear others' experiences in
cross-language idea implementation.
It can be good, but it can also be dangerous.
For example, I've seen code from a Lisp fan who insisted on implementing Lisp primitives like car and cdr, and then writing everything in Lisp style with a Lisp-like API where all the parameters were lists of lists of lists. The resulting code worked fine, but it was basically unmaintainable by anyone else; I'm a Scheme fan, and even I found it impenetrable.
You could do that easily in Ruby. Would it be a good idea? I don't think so. But a Common Lisp developer would probably describe it as merely borrowing a highly effective paradigm from a more mature and powerful language.
I think that coding style transplants depend a lot on the specifics of the donor and recipient languages--how similar they are, and how flexible the recipient language is. Trying to implement reflection and duck typing in FORTH is always going to be hard work, because it's just not that kind of language; and trying to do it in Java is going to be painful because it's such a rigid and fussy language.
There's something to be said for using the most obvious implementation method that the language best supports, even if it's not necessarily the most elegant method.
There's a similar issue around object orientation. Some people get so hooked on the idea of OO that they end up writing code where every piece of the problem is decomposed into objects; they develop an almost pathological aversion to simple imperative programming. The result is usually an API that's horribly bloated and complex, and code where there ae so many classes that working out what's going on resembles the old spaghetti code problems of (say) FORTRAN.
Again, my feeling is that objects should be used where it makes sense--to model classes of object in the problem domain, and to provide an API that's as simple as possible. If you then end up with a method that has a page or two of imperative code, that's not necessarily a sign of failure. Some tasks *are* best expressed as "Do these ten things in sequence".
Let's say that I have this...friend...um yea. And this 'friend' was
tossing around ideas about what a rubyesque GUI toolkit API would look
like. What would people think of something like this for event
handling?:
...
button.when_pushed do
puts "Hey, don't push my buttons!"
end
...
Hmm, I do not know. Maybe when you spent time to get to know something in depth, you start appreciating it more. Maybe because it allows me to refactor legacy C code to gradually get to OO implementation with all its benefits (true unit testing, code reuse, etc.)
If you like Ruby, and want to take legacy C code and make it OO, then you really owe it to yourself to try Objective-C. You should be able to learn it in a weekend. (Unlike C++.)
Personally, having written in both, I can't understand why so many people use C++ and so few use Objective-C.
mathew
···
On 7/14/05, Gennady Bystritksy <gfb@tonesoft.com> wrote:
Inheritance just for the purpose to add callbacks/configuration
already proved to be wrong a long time ago. The only framework which
tried this was self, but as self is OO without classes it's not
comparable.
wxWindows (now wxWidgets, I'm told) does this, and made programming
windows in C++ oodles easier for me. But that's neither here nor there.
Sorry but this is not true.
WxWindows never did this. It has an event table to dispatch events
to handlers methods.
Of couse you can do it with every toolkit but it nowhere the
recommended programming style and there are good reasons for it.
···
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
clicking on the 'last 90 days' i get: May 7, 2005 for the last update
ouch.
seeing as arachno-ruby uses fxruby, and i've been fairly impressed
with that ide, i'm probably going to lean towards that...
No ArachnoRuby uses FOX not FXRuby. I've written and modified a
lot of the original FOX widgets.
You can also modify widgets with fxruby but it is sometimes
more trouble to do it with ruby and it can result in bad performance
if you do it in a simple, non optimized way. Drawing and
layout calculation can take a serious amount of pure ruby instructions
(integer operations and function calls through a lot of wrappers)
which might be factor 100x slower then C.
And for wxruby: I wouldn't give to much attention to the last update
date. Whats important is how the CVS changed over the last 3 month.
If there are no improvements it's a clear sign of a problem.
···
mathew wrote on 7/18/2005 12:30 PM:
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
I, personally, would prefer something more along the lines:
button.on_event( :push ) do
puts "Hey, don't push my buttons!"
end
I happen to have the same "friend", though I notice he's been in a
coma while his alter ego has been busy with life, marriage and such.
Jacob Fugal
···
On 7/18/05, Daniel Amelang <daniel.amelang@gmail.com> wrote:
Let's say that I have this...friend...um yea. And this 'friend' was
tossing around ideas about what a rubyesque GUI toolkit API would look
like. What would people think of something like this for event
handling?:
...
button.when_pushed do
puts "Hey, don't push my buttons!"
end
...
Sorry this isn't a reply to the Tk problems. I would like to say that
ruby has ruined all other languages for me except for c (and hopefully
lisp when I get to learn it). I find that I am now writing a lot of c
in the ruby fashion and then calling it from ruby. I am trying to
write some game engine code (just playing around at the moment) and
wrappering it with ruby.
I write Java and C# for work and I am always sad. I really miss
closures and other key features. I am currently writing an application
with an existing library and if I had closures I would be able to make
changes to the existing code base in a really simple and elegant
manner but without them I either have to spend a lot of time
refactoring or just hack something together.
Ruby has quite easily become my favorite language. Maybe this will
change when I learn lisp but for the moment I am really happy with it.
···
On 7/18/05, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
Hi,
In message "Re: ] Re: Ruby has ruined my Java" > on Mon, 18 Jul 2005 08:01:02 +0900, Hidetoshi NAGAI <nagai@ai.kyutech.ac.jp> writes:
>> b = TkButton.new(nil, "text"=>"quit").pack
>> b.command { exit }
>
>Or,
> b = TkButton.new(nil, :text=>'quit', :command=>proc{exit}).pack
>
>Why did you write it in two lines?
Perhaps he saw my recent slide, which tried to explain callback
blocks.
WxWindows never did this. It has an event table to dispatch events
to handlers methods.
Ah. You are correct. It's been a while. My mistake. You don't have to, but it's often the easiest way to add handler methods, child windows, etc. and is littered in all their examples. At the very least, you have to subclass and override a couple of methods from wxApp, but I also remember subclassing wxFrame and wxPanel. You are correct, though, in that I never subclassed wxButton.
Of couse you can do it with every toolkit but it nowhere the
recommended programming style and there are good reasons for it.
So, tell my why you prefer the on_event( :event_type ) syntax?
I prefer the when_pushed syntax because of the readablity and
abstraction of events altogether. 'button when pushed do this' feels
very natural. But maybe it feels very unnatural for others. 'button on
event push' is OK with me, it's the fxRuby way after all.
The when_pushed method would actually (via the magic of method missing
possibly) translate to something like register_handler (:push, block)
under the hood.
This looks like it is more flexible .. but it requires the user of the
library to write a dispatcher function. And since ruby is dynamic you do
not need to force users into writing dispatchers to get flexibility.
So I like the first one better.
Thanks
Michal Suchanek
···
On Tue, Jul 19, 2005 at 06:55:23AM +0900, Jacob Fugal wrote:
On 7/18/05, Daniel Amelang <daniel.amelang@gmail.com> wrote:
> Let's say that I have this...friend...um yea. And this 'friend' was
> tossing around ideas about what a rubyesque GUI toolkit API would look
> like. What would people think of something like this for event
> handling?:
>
> ...
> button.when_pushed do
> puts "Hey, don't push my buttons!"
> end
> ...
I, personally, would prefer something more along the lines:
button.on_event( :push ) do
puts "Hey, don't push my buttons!"
end
I don't know, it's just preference. Your syntax is a good
alternative. But I'll take a stab at explaining my preference
anyway...
I think the main difference is the conciseness of the grammar style,
and an easier reflection between event handling and event generation.
For one thing, the 'when_pushed' variant would need a translation in
method_missing to turn 'pushed' into :push. The 'on_*' route doesn't
necessarily preclude method_missing abstraction either:
module EventListener
def register_handler( event_name, &action ) @actions ||= {} @actions[event_name] ||= @actions[event_name] << action
end
def handle_event( event_name )
if @actions[event_name] @actions[event_name].each { |action| action[self] }
end
end
def method_missing( symbol, *args, &block )
if /^on_/.match( symbol )
self.register_handler( symbol.to_s.gsub(/^on_/, '').to_sym, *args ) &block
else
self.handle_event( symbol )
end
end
end
class Button
include EventListener
end
button = Button.new
button.on_push do |b|
puts "Don't push my buttons!"
end
button.push
···
On 7/18/05, Daniel Amelang <daniel.amelang@gmail.com> wrote:
So, tell my why you prefer the on_event( :event_type ) syntax?
I prefer the when_pushed syntax because of the readablity and
abstraction of events altogether. 'button when pushed do this' feels
very natural. But maybe it feels very unnatural for others. 'button on
event push' is OK with me, it's the fxRuby way after all.
The when_pushed method would actually (via the magic of method missing
possibly) translate to something like register_handler (:push, block)
under the hood.
On Wed, Jul 20, 2005 at 06:40:07AM +0900, Michal 'hramrach' Suchanek wrote:
This looks like it is more flexible .. but it requires the user of the
library to write a dispatcher function. And since ruby is dynamic you do
not need to force users into writing dispatchers to get flexibility.
First, the user doesn't have to write the dispatcher, that's provided
by the library. You mention in a followup that you were confused, so
I'll forgive you for that I know I get confused quite often
However, you do bring up a good point: since ruby is dynamic you
shouldn't need to write dispatchers. Why can't I just do this:
class MyButton < Button
# override what happens on a push, then simply have windowing code
# call methods, rather than sending events
def push
puts "Don't push my buttons!"
end
end
button = MyButton.new
button.push
First off, as has been mentioned in another thread, inheritance just
to define new events isn't really the best idea. Ok, easy to fix:
button = Button.new
class << button
def push
puts "Don't push my buttons!"
end
end
button.push
We could even wrap that in a method to make the syntax cleaner. With a
clean syntax, we can even switch out what the actions are based on
runtime times without ugliness. Looking good. But there are still two
more objections which lead me to suggest a dispatcher model: shared
actions and multiple actions tied to the same event. Neither of these
work very well if at all without a stored proc/dispatch model.
Jacob Fugal
···
On 7/19/05, Michal 'hramrach' Suchanek <hramrach@centrum.cz> wrote:
On Tue, Jul 19, 2005 at 06:55:23AM +0900, Jacob Fugal wrote:
> On 7/18/05, Daniel Amelang <daniel.amelang@gmail.com> wrote:
> > ...
> > button.when_pushed do
> > puts "Hey, don't push my buttons!"
> > end
> > ...
>
> I, personally, would prefer something more along the lines:
>
> button.on_event( :push ) do
> puts "Hey, don't push my buttons!"
> end
This looks like it is more flexible .. but it requires the user of the
library to write a dispatcher function. And since ruby is dynamic you do
not need to force users into writing dispatchers to get flexibility.
I, personally, would prefer something more along the lines:
button.on_event( :push ) do
puts "Hey, don't push my buttons!"
end
This looks like it is more flexible .. but it requires the user of the
library to write a dispatcher function. And since ruby is dynamic you do
not need to force users into writing dispatchers to get flexibility.
So I like the first one better.
have someone noticed that this is how ruvy-gtk2 works?
