I'm curious what the experts on this list might think of this.
My code falls into chunks. Some of those chunks correspond to methods,
classes, or modules. Many do not. For the ones that do not, I do something
like this (literally, or in my head)
module A
# classes about foo
class C1
# methods about bar
def m1 ...
def m2
def m3
# do stuff about baz
baz1
baz2
# do other stuff
other
end
end
end
The Leo editor, which supports outline-based programming with a tree of
nested sections + cross-tree references + some literate programming
features, got me thinking: Could Ruby help me with this chunking? Something
like this
module A
section foo
class C1
section bar begin
def m1
def m2
def m3
section baz begin
baz1
baz2
end
other
end
end
end
end
(note: the section "foo" within module A would be somewhat like a nested
module with an auto-include)
The names on sections could be optional. Even without names, and with
absolutely minimal language processing, my number of comments would be
reduced, scope would be language-demarcated, folding etc. would be simpler.
The cost would be some extra begin-ends or {}.
I could then easily see an outline-styled editor for writing my ruby code.
The names on sections, if provided, could be used for various things as
well. For example, you might simply reference a section on one place, but
define it elsewhere. This would extend a tree-based outline-style editor
into one more like Leo, allowing any sub-tree to be referenced from
elsewhere.
Hm, would be nice to be able to group or categorize similar methods
together and generate sections in the RDoc output.
What you suppose is of course a bit different, not sure whether I'd like
to use a special editor.
Regards,
Michael
···
On Sun, Nov 14, 2004 at 08:43:23AM +0900, itsme213 wrote:
I'm curious what the experts on this list might think of this.
My code falls into chunks. Some of those chunks correspond to methods,
classes, or modules. Many do not. For the ones that do not, I do something
like this (literally, or in my head)
module A
# classes about foo
class C1
# methods about bar
def m1 ...
def m2
def m3
# do stuff about baz
baz1
baz2
# do other stuff
other
end
end
end
I'm curious what the experts on this list might think of this.
My code falls into chunks. Some of those chunks correspond to methods,
classes, or modules. Many do not. For the ones that do not, I do something
like this (literally, or in my head)
[snip]
Hmmm. This is just me, but when I find myself with a method that can be logically broken down into different functional parts, I typically refactor the method, so that each of those parts is another method. In other words:
def foo
# bar stuff
...
# baz stuff
...
end
Becomes:
def foo
bar
baz
end
def bar
...
end
def baz
...
end
And if I find that I have methods that should be grouped in clusters, I typically refactor _those_ into new classes, so:
class A
# foo things
...
# bar things
...
# baz things
...
end
becomes:
class A
attr_reader :foo
attr_reader :bar
attr_reader :baz
end
class Foo
...
end
class Bar
...
end
class Baz
...
end
AND, if I find that I have classes that need grouping, I refactor them out into new modules...and so forth. This approach works really well with dependency injection, btw.
"Michael Neumann" <mneumann@ntecs.de> wrote in message
What you suppose is of course a bit different, not sure whether I'd like
to use a special editor.
I did not mean to suggest that at all; it was simply my link to Leo, whose
underlying metaphor is quite eye-opening. Besides, a smart folding mode in
any editor could exploit it as well.
"Jamis Buck" <jgb3@email.byu.edu> wrote in message
Hmmm. This is just me, but when I find myself with a method that can be
logically broken down into different functional parts, I typically
refactor the method, so that each of those parts is another method.
Sometimes this is a good choice. At other times it becomes contorted since
it loses shared context (local variables, parameters of the parent method)
and so adds unnecessary parameter passing. I was talking about those other
times.
def foo (w, x)
# section 1
y = a(w)
z = b(y)
# section 2
...
end
And if I find that I have methods that should be grouped in clusters, I
typically refactor _those_ into new classes, so:
Again, sometimes this works. You lose the shared context of the class
(instance variables etc) and that sometimes makes things contorted, imo.
Sometimes defining a module inline + including it immediately works too.
AND, if I find that I have classes that need grouping, I refactor them
out into new modules...and so forth.