From noreply at rubyforge.org Thu May 3 15:11:57 2007 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 May 2007 15:11:57 -0400 (EDT) Subject: [Facets] [ facets-Bugs-10561 ] Dictionary#delete_if does not yield iterated keys/values to block Message-ID: <20070503191157.590245240BBE@rubyforge.org> Bugs item #10561, was opened at 2007-05-03 15:11 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=10561&group_id=804 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Riley Lynch (rlynch) Assigned to: Nobody (None) Summary: Dictionary#delete_if does not yield iterated keys/values to block Initial Comment: Dictionary#delete_if reads: def delete_if order.clone.each { |k| delete k if yield } self end The block passed to delete_if is being called without passing the iterated keys and values as arguments. This also breaks #reject and #reject! . For compatibility with ::Hash#delete_if, it should pass both the key and the value: def delete_if order.clone.each { |k| delete k if yield(k,self[k]) } self end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=3169&aid=10561&group_id=804 From transfire at gmail.com Tue May 8 13:07:14 2007 From: transfire at gmail.com (Trans) Date: Tue, 08 May 2007 17:07:14 -0000 Subject: [Facets] Facets 2.0 Home Stretch In-Reply-To: <1176502987.748035.13280@n59g2000hsh.googlegroups.com> References: <1176502987.748035.13280@n59g2000hsh.googlegroups.com> Message-ID: <1178644034.939372.320940@h2g2000hsg.googlegroups.com> After more discussions and a survey, I've further refined the division and naming of Facets subprojects. There will be, at least, the following packages in the Facets repository: CoreMethods CoreModules AdaptiveBase AdaptiveCache LiveCommand LiveLibrary LiveConcern LiveNotes LiveUnits FileShell At this point I am debating two things: 1) Whether to use "Base" instead of "Core" as the prefix for the first two, ie. BaseMethods and BaseModules, or perhaps go back to NanoMethods and MegaModules instead. 2) Whether to use "Open" instead of "Live" for the later packages (including FileShell --eg. OpenShell) or some combination of the two --"Live" for some and "Open" for others. Please offer any opinions you have on this. Once this is settled I'll finally be able to move forward. Praise the Mother! T. From transfire at gmail.com Fri May 11 14:51:27 2007 From: transfire at gmail.com (Trans) Date: Fri, 11 May 2007 18:51:27 -0000 Subject: [Facets] Facets 2.0 Home Stretch In-Reply-To: <1176502987.748035.13280@n59g2000hsh.googlegroups.com> References: <1176502987.748035.13280@n59g2000hsh.googlegroups.com> Message-ID: <1178909487.543378.113120@e65g2000hsc.googlegroups.com> Can you tell I'm running around in circles on this? I keep thinking "okay, that's going to be it", but I never quite make it. I think one of the fundamental distinctions that I've been missing is that which lies between a common utility, and a more specialized tool. For example, the Command base class is more specialized, while the ANSICode module is more of a common utility. Ultimately I think it would be nice to create a more cohesive tool that covers the full- spectrum of requirements for console based apps. While it would make sense to include all the components needed for this in the single package, eg."Comrade", this would discourage others from using those parts for their own equivalent utilities. In other words, by including ANSICode in "Comrade", I've discouraged others from creating there own command-line solutions that could re-utilize ANSICode. For this reason, one can argue that something like ANSICode would be better off as it's own package. However packaging systems are generally poorly suited to small reusable libs like this, which typically having but a single file. For example, RubyGems package format and conventions for project layouts are bulky relative to this need, and it is inefficient in it's effects on Ruby's loadpath system. Also, it may be foolish to think an ANSICode library would get much independent use anyway. If someone needed it for another application they'd might just copy and paste it into their own project --avoiding the dependency. That's the other issue here. With so many small libraries one could easily have dozens of such dependencies per application. While that upholds the common mantra of "code reuse", it also comes at the practical costs of dependency. This is the primary reason I came up with the idea of GemBundles. So I suppose I have to ask, what are we after? Is it to create comprehensive solutions such as Comrade? Or simply to offer essentially independent reusable components such as Command and ANSICode? And if the later, is it acceptable to distribute so many small packages, or must we accept packages groups even though it may discourage reuse. T. From transfire at gmail.com Fri May 11 17:13:06 2007 From: transfire at gmail.com (Trans) Date: Fri, 11 May 2007 21:13:06 -0000 Subject: [Facets] Unique Names vs Uniform Names Unique names provide maximum independence. This allows for greater flexability in mixing and matching tools to requirements. However they require greater familiarity b/c various names must be remembered. In addition, this puts pressure on each package to only contain files that partake in a more cohesive application. In this case, parts of Facets might end-up in packages such as: kickstand (additions to standard library) annotate (annotations) taopoint (aop library) fileshell (file tools) freeload (net-based require and module tools) comrade (command line tools) magicdot (functor) The names are light and entertainting, but their usage is not immediately evident just by the names. Of course, we can use names that are less entertaining and more to the point, such as "cliutils" instead of "comrade". But this doesn't change much as far as library usage. While it is easier to recognize for what it is, it likewise looses brandability. Gogin further, uniform names allow a large support library like Facets to be broken down into categories. This makes them more convenient in that they are easier to recall. Plus the files within these catagories do not neccessiarily need to be as cohesive. Facets categories could be: facets-core facets-meta facets-file facets-math facets-cli facets-aop facets-ann facets-mix facets-struct facets-open facets-misc Most of these are fairly self-explanitory. It is interesting to note that one of the categories is so small and cohesive that it isn't really a category at all, but rather has the feel of an independent library (namely 'ann'). Indeed, if we continued to break down these categories further, each part would eventually fall out as it's own fully independent library --for example: ansicode and multition. But that would entail a huge set of libraries, each of which seems too small to fully warrant the many packages. One of the downsides of categorization is that pressure for cohesion lies between the whole library, not just the pacakged parts. Clearly it is expected that every part of Facets will work well with the rest. In addition, marketing/branding is hurt since there are no coined names to "sell". We have only "Facets", which is good in itself, but it's not well directed to specific problems. Someone in the market for a CLI tool will not be as easily taken with a lib called Facets-CLI, since it suggests the "baggage" of the other Facets tools (even if it is not necessarily the case). Unique vs Uniform In-Reply-To: <1178909487.543378.113120@e65g2000hsc.googlegroups.com> References: <1176502987.748035.13280@n59g2000hsh.googlegroups.com> <1178909487.543378.113120@e65g2000hsc.googlegroups.com> Message-ID: <1178917986.843523.324660@u30g2000hsc.googlegroups.com> Unique names provide maximum independence. This allows for greater flexibility in mixing and matching tools to requirements. However they require greater familiarity b/c various names must be remembered. In addition, this puts pressure on each package to only contain files that partake in a more cohesive application. In this case, parts of Facets might end-up in packages such as: kickstand (additions to standard library) annotate (annotations) taopoint (aop library) fileshell (file tools) freeload (net-based require and module tools) comrade (command line tools) magicdot (functor) The names are light and entertaining, but their usage is not immediately evident just by the names. Of course, we can use names that are less entertaining and more to the point, such as "cliutils" instead of "comrade". But this doesn't change much as far as library usage. While easier to recognize for what it is, it likewise looses brand-ability. Taking the other approach, uniform names allow a large support library like Facets to be broken down into categories. This makes them more convenient in that they are easier to recall. Plus the files within these categories do not necessarily need to be as cohesive. Facets categories could be: facets-core facets-meta facets-file facets-math facets-cli facets-aop facets-ann facets-mix facets-struct facets-open facets-misc Most of these are fairly self-explanatory. It is interesting to note that one of the categories is so small and cohesive that it isn't really a category at all, but rather fits the criteria of an independent library (namely 'ann'). Indeed, if we continued to break down these categories further, each part would eventually fall out as it's own fully independent library --for example: ansicode and multition. But that would entail a huge set of libraries, each of which seems too small to fully warrant the many packages (?) One of the downsides of uniformity is that pressure for cohesion lies between the whole library, not just the packaged parts. Clearly it is expected that every part of Facets will work well with the rest. In addition, marketing/branding is hurt since there are no coined names to "sell". We have only "Facets", which is good in itself, but it's not as well directed to specific problems. Someone in the market for a CLI tool will not be as easily taken with a lib called Facets-CLI, since it suggests the "baggage" of the other Facets tools (even if it is not necessarily the case). As you can see, I'm just trying to think out load here. T. From transfire at gmail.com Fri May 11 17:58:21 2007 From: transfire at gmail.com (Trans) Date: Fri, 11 May 2007 21:58:21 -0000 Subject: [Facets] Unique Names vs. Uniform Names Message-ID: <1178920701.501762.291610@o5g2000hsb.googlegroups.com> Unique names provide maximum independence. This allows for greater flexibility in mixing and matching tools to requirements. However they require greater familiarity b/c various names must be remembered. In addition, this puts pressure on each package to only contain files that partake in a more cohesive application. In this case, parts of Facets might end-up in packages such as: kickstand (additions to standard library) annotate (annotations) taopoint (aop library) fileshell (file tools) freeload (net-based require and module tools) comrade (command line tools) magicdot (functor) The names are light and entertaining, but their usage is not immediately evident just by the names. Of course, we can use names that are less entertaining and more to the point, such as "cliutils" instead of "comrade". But this doesn't change much as far as library usage. While easier to recognize for what it is, it likewise looses brand-ability. Taking the other approach, uniform names allow a large support library like Facets to be broken down into categories. This makes them more convenient in that they are easier to recall. Plus the files within these categories do not necessarily need to be as cohesive. Facets categories could be: facets-core facets-meta facets-file facets-math facets-cli facets-aop facets-ann facets-mix facets-struct facets-open facets-misc Most of these are fairly self-explanatory. It is interesting to note that one of the categories is so small and cohesive that it isn't really a category at all, but rather fits the criteria of an independent library (namely 'ann'). Indeed, if we continued to break down these categories further, each part would eventually fall out as it's own fully independent library --for example: ansicode and multition. But that would entail a huge set of libraries, each of which seems too small to fully warrant the many packages (?) One of the downsides of uniformity is that pressure for cohesion lies between the whole library, not just the packaged parts. Clearly it is expected that every part of Facets will work well with the rest. In addition, marketing/branding is hurt since there are no coined names to "sell". We have only "Facets", which is good in itself, but it's not as well directed to specific problems. Someone in the market for a CLI tool will not be as easily taken with a lib called Facets-CLI, since it suggests the "baggage" of the other Facets tools (even if it is not necessarily the case). As you can see, I'm just trying to think out load here. T. From transfire at gmail.com Sat May 12 12:30:32 2007 From: transfire at gmail.com (Trans) Date: Sat, 12 May 2007 16:30:32 -0000 Subject: [Facets] Unique Names vs. Uniform Names In-Reply-To: <1178920701.501762.291610@o5g2000hsb.googlegroups.com> References: <1178920701.501762.291610@o5g2000hsb.googlegroups.com> Message-ID: <1178987432.741079.171640@h2g2000hsg.googlegroups.com> If you hadn't yet noticed, the reason this issue is driving me so crazy is b/c I don't like to do anything unless there is some good rationality for doing so. So far there hasn't been much firm evidence for pursuing one path over another in this quest of organizing Facets into more manageable pieces. That's why I held an inductive poll. The results of which were rather interesting in that they appear slightly contradictory. While most indicated a preference toward categorical names, when it came down to actual examples they leaned toward creative names, with the single exception of names that were dead simple --essentially too simple. Even so I still wanted some deductive reasons for taking an approach, and I think I've finally made some head way in that. I believe I've ruled out the "categorical approach" I've previously talked about. My reasoning is this: Categories actually do less for the end-user. They seem nice at first, but mostly just help the developer by breaking the whole library into more manageable pieces, but those pieces aren't nearly as effective as encapsulating USECASE. For example "facets-meta" holds meta-programming tools. That helps the end-user very little since different meta-programming tools can be worlds apart. The end-user is barely better off than knowing that a single package "facets" has such tools. Likewise for "facets- mix" (mixins), "facets-misc", and so forth. The situation gets a bit better for "facets-cli", and much better for "facets-ann", but that's because their divisions are narrower and more focused to a usecase, to the point that they almost beg for their own independence. And so I've concluded that functional categorization like this is less effective. That leaves me with the choice between "solution organization" or "low- level separation". Solution organization means extracting closely related files and making more cohesive packages out of them with their own brand names, eg. Comrade. Anything that does not omit of this ability stays in a single "general purpose" library. These new packages can still remain part of a larger repository (eg. Facets), but they would nonetheless be effectively independent. The only question that would remain if this path is taken, is whether to use highly creative names, like Comrade, or more subdued names, like BaseCommand. Low-level separation means making any independently usable library a separate package. After some thought on this, if I were to do it, I think I'd use the prefix "fx_" for the many small packages. To give you a taste of this approach, here is a list of about half of all the packages that would come out of it: fx_progressbar fx_crypt fx_inheritor fx_snapshot fx_basicobject fx_dependency fx_populate fx_system fx_behavior fx_lazy fx_promoteself fx_timer fx_binreadable fx_metaphone fx_mainmodule fx_recorder fx_typecast fx_buildingblock fx_reference fx_uninheritable fx_cachedelegator fx_enumerable fx_multiton fx_reflection fx_classmethods fx_expirable fx_rwdelegator fx_cloneable fx_functor fx_nullclass fx_coroutine fx_hashbuilder fx_overload fx_semaphore fx_association fx_autoarray fx_dictionary fx_elementor fx_heap fx_linkedlist fx_lrucache fx_opencascade fx_opencollection fx_openobject fx_orderedhash fx_pool fx_statichash fx_syncobjects fx_tuple fx_version fx_constants fx_infinity fx_interval fx_ioredirect The advantage of course is the ability to pick and choose just what one wants/needs and nothing more. It's the ultimate in re-usability. However, on the downside, it really makes the need for GemBundles an absolutely pressing issue --I doubt few people like the idea of 20 independent gem dependencies for their project. Further, it requires a little extra work to maintain such a large set of packages. And perhaps worst of all, it also doesn't encourage much cohesion, i.e if fx_infinity doesn't work with fx_interval, it would be difficult to know, since the tests would be separated as well. T. From transfire at gmail.com Wed May 16 12:51:10 2007 From: transfire at gmail.com (Trans) Date: Wed, 16 May 2007 16:51:10 -0000 Subject: [Facets] Unique Names vs. Uniform Names In-Reply-To: <1178987432.741079.171640@h2g2000hsg.googlegroups.com> References: <1178920701.501762.291610@o5g2000hsb.googlegroups.com> <1178987432.741079.171640@h2g2000hsg.googlegroups.com> Message-ID: <1179334270.831671.57470@o5g2000hsb.googlegroups.com> Good news on the reorganization front. My new "solutions orientation" has born some nice fruit. I hadn't clearly realized it before, but my previous categorizations were discordant. On one had I was organizing some libs by usage while on the other I was organizing by type of programming construct. For example, command line tools vs. module mixins. It's a bad match. So I have gone back and made sweeping transformations in organization based solely on usage. With the exception of minor discernments I still need to nail down, I am very satisfied with the new sorting. These categories are so far: General low-level / meta programming Aspect Oriented Programming Attributes and Annotations Library Loading Module Inclusion Text Manipulation Data Structures Mathematics DateTime/GPS Filesystem / IO Networking Command Line / Console I may combine Networking with Filesystem/IO b/c there are so few networking related libs in Facets. I also may combine Library Loading and Module Inclusion since there is some conceptual overlap between them. But those minor details aside, like I said, I am very happy with this. It makes a lot more sense as far as improving development, as well as delivering focused solutions to end-users. However, I am still left with an awful naming problem. I really don't like anything I've come up with. When picking creative names, I really only like three or four that I've considered (Comrade, Textile, Metal, Taopoint) It becomes increasing burdensome to think of good creative names that fit in well with others. Moreover, I'm not so sure I like the idea of having to use all these names in require statements. Eg. require 'comrade/command' require 'taopoint/cut' require 'textile/inflect' But perhaps I should just accept this and keep working to find acceptable names for the other 6 or 7 groups? The alternative of hyphenated names doesn't seem any better (eg. facets-file). It can be equally difficult to find a good concise descriptive word for them, and the "facets" prefix conveys a lack of independence, which I don't want. The benefit though is that separate require spaces aren't important. require 'facets/command' require 'facets/cut' require 'facets/inflect' Is fine and obviously be a bit easier on the mind. Because of this lingering dilemma I am considering a potential third approach. In the spirit of Oniguruma, I was thinking about naming each group by a related Japanese word. A few potential examples: zokusei raiburai tekisuto kouzou hiduke suugaku And regardless of the independent names, the require statements could still just use "facets/command", etc. Of course the downside here is that those words have zero intrinsic meaning to non-Japanese speakers. T. From transfire at gmail.com Wed May 30 16:14:01 2007 From: transfire at gmail.com (Trans) Date: Wed, 30 May 2007 20:14:01 -0000 Subject: [Facets] Facets 2.0 Home Stretch In-Reply-To: <1178644034.939372.320940@h2g2000hsg.googlegroups.com> References: <1176502987.748035.13280@n59g2000hsh.googlegroups.com> <1178644034.939372.320940@h2g2000hsg.googlegroups.com> Message-ID: <1180556041.350595.54480@h2g2000hsg.googlegroups.com> Hi, I'm having trouble recognizing any solution-based categories to organize these remaining libs. Any ideas? See any nameable patterns? coroutine.rb daemonize.rb lazy.rb nilasempty.rb nilcomparable.rb procbind.rb rbsystem.rb recorder.rb reference.rb rwdelegator.rb semaphore.rb snapshot.rb todata.rb typecast.rb infinity.rb interval.rb quaternion.rb random.rb timer.rb Thanks, T. From transfire at gmail.com Wed May 30 16:25:50 2007 From: transfire at gmail.com (Trans) Date: Wed, 30 May 2007 20:25:50 -0000 Subject: [Facets] Facets 2.0 Home Stretch In-Reply-To: <1178644034.939372.320940@h2g2000hsg.googlegroups.com> References: <1176502987.748035.13280@n59g2000hsh.googlegroups.com> <1178644034.939372.320940@h2g2000hsg.googlegroups.com> Message-ID: <1180556750.376588.104630@o5g2000hsb.googlegroups.com> BTW, I had a good discussion with Peter Vanbroekhoven about the organization of Facets 2.0. He had some excellent notions on the matter which really helped me see this to a rational conclusion. It took some herculean effort (basically my roll-playing with all potential options) but the final result is proving to be well worth all the hair-pulling effort. The game really is a bit "best of both worlds". I divided up all of Facets according to "solutions". For instance CLI-based libs are in one package, AOP-related libs in another, and so on. This solution- based approach had a huge positive effect on the layout. However, full- on solution-based divisions were still lacking in one important respect. Facets needed a central core which represented it's common functionality. So I took a step back and put all _essential_ core extensions in a separate package. Though they cover a variety of solutions, these extensions are the ones you might half expect to already be in Ruby proper. As such all of them are easily (though optionally) loadable via a single require. I also made a secondary package for extensions to Ruby's standard libs --since these aren't loaded unless specifically required. So those are the two exceptions to the pure solution-based divisions of Facets. As for names of each of division, I was looking at highly _why-esque (ie. creative) names, but I'm starting to lean toward simpler, more concise names; kind of taking the Microsoft approach to marketing in that regard (eg. Microsoft Surface). In any case the ultimate result will be packages with names like "facets_core" and require statements like 'facets/ core/..'. With the potential for shortcuts (eg. require 'core') and perhaps redirecting gem packages (eg. "gem install core" would install facets_core as a dependency). So that's the summary of what's coming down the line. Anyone who's followed my dizzying ranting and raving on this matter these last months can understand just how much I'm look forward to getting these packages out the door :) T.