unused methods
Locked
 
|
Keith Hodges wrote:
> The seaside team has a policy of removing methods that are not actually > used by the framework. [...snip...] (an example of this is that > #hasGroupNamed: is not provided in the interface to the application > configuration because seaside has no need of it. Hi Keith, It's just a matter of finding a balance: there are plenty of methods in the framework that are not sent from within. Mostly I would just rather see methods added as people need them rather than implementing every method we can think of and then being unable to remove, rename, or change the behaviour of them because people "might" be using them. The more methods we add, the more code we need to maintain and the more code people need to wade through. By #hasGroupNamed: I assume you are refering to behaviour something like this? aConfiguration allAttributes anySatisfy: [:ea | ea group = #server] I don't object to a method such as that existing /per se/ but the above code seems fairly clear, no? And if we were to add #hasGroupNamed:, do we need #hasAttributeWithLabel:, #hasAdvancedAttributes, #hasBooleanAttributes, #allBooleanAttributes, #allAttributesInGroup:, and so on? We try to anticipate users' needs when possible but we can't predict every query that a user might want to make... If only one person is using a method, it is easily added as a class extension. If many users are clamouring for it, then of course we would look at adding it. Julian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
But please, do finally think of these:
a) Do document methods! b) Look at the many misleading method names For a novice it's extremely difficult getting into Seaside, mainly because it's not or badly documented. More here: http://thesmalltalkblog.blogspot.com/2009/04/to-documents-or-not-to-be.html
-- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Julian Fitzell-2
Julian Fitzell wrote:
> Keith Hodges wrote: > >> The seaside team has a policy of removing methods that are not actually >> used by the framework. [...snip...] (an example of this is that >> #hasGroupNamed: is not provided in the interface to the application >> configuration because seaside has no need of it. >> > > Hi Keith, > > It's just a matter of finding a balance: there are plenty of methods > in the framework that are not sent from within. Mostly I would just > rather see methods added as people need them rather than implementing > every method we can think of and then being unable to remove, rename, > or change the behaviour of them because people "might" be using them. > The more methods we add, the more code we need to maintain and the > more code people need to wade through. > > By #hasGroupNamed: I assume you are refering to behaviour something like this? > > aConfiguration allAttributes anySatisfy: [:ea | ea group = #server] > > I don't object to a method such as that existing /per se/ but the > above code seems fairly clear, no? And if we were to add > #hasGroupNamed:, do we need #hasAttributeWithLabel:, > #hasAdvancedAttributes, #hasBooleanAttributes, #allBooleanAttributes, > #allAttributesInGroup:, and so on? We try to anticipate users' needs > when possible but we can't predict every query that a user might want > to make... > > If only one person is using a method, it is easily added as a class > extension. If many users are clamouring for it, then of course we > would look at adding it. > - Seaside-Cruft say - instead of outright deleting them? Perhaps then people who wanted those removed methods would have an easy way to "regain" the methods, by simply moving methods from Seaside-Cruft to their own package. frank _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
>>>>> "Frank" == Frank Shearar <[hidden email]> writes:
Frank> How difficult would it be to move these unused methods to a new package - Frank> Seaside-Cruft say - instead of outright deleting them? Frank> Perhaps then people who wanted those removed methods would have an easy way to Frank> "regain" the methods, by simply moving methods from Seaside-Cruft to their own Frank> package. It's a maintenance issue. Suppose a method gets "copied", but then reintrodced mainline, perhaps even with a bug fix. Ouch. Fragile code, at your service. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Randal L. Schwartz wrote:
>>>>>> "Frank" == Frank Shearar <[hidden email]> writes: >>>>>> > > Frank> How difficult would it be to move these unused methods to a new package - > Frank> Seaside-Cruft say - instead of outright deleting them? > That is what Seaside28Jetsam is. http://en.wikipedia.org/wiki/Jetsam Keith _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Frank Shearar
On Sun, Apr 19, 2009 at 12:09 PM, Frank Shearar
<[hidden email]> wrote: > How difficult would it be to move these unused methods to a new package - > Seaside-Cruft say - instead of outright deleting them? My point is that we try to find a balance so that we don't have to delete methods. If we add too much stuff that essentially nobody uses, it's a pain to delete later because "essentially" does not equal "literally". I'd rather just guess conservatively and wait and see what people think is missing before adding them in the first place. When we do decide we need to remove methods, we usually deprecate them so they will signal notifications but continue to work for some period of time. If somebody wants to provide a separate package with methods that are no longer even deprecated, that's certainly fine but as Randal says, it's a bit a maintenance problem for us to do so. Julian _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Julian Fitzell wrote:
> On Sun, Apr 19, 2009 at 12:09 PM, Frank Shearar > <[hidden email]> wrote: > >> How difficult would it be to move these unused methods to a new package - >> Seaside-Cruft say - instead of outright deleting them? >> > > My point is that we try to find a balance so that we don't have to > delete methods. If we add too much stuff that essentially nobody uses, > it's a pain to delete later because "essentially" does not equal > "literally". I'd rather just guess conservatively and wait and see > what people think is missing before adding them in the first place. > could almost have one's cake and eat it, and it looks like Keith's saying that that's exactly what he's doing. > When we do decide we need to remove methods, we usually deprecate them > so they will signal notifications but continue to work for some period > of time. If somebody wants to provide a separate package with methods > that are no longer even deprecated, that's certainly fine but as > Randal says, it's a bit a maintenance problem for us to do so. > Yes. One can well see the fallout when someone uses a "cruft method" that belonged to an older version that no longer works... and then Seaside gets blamed, for moving on. frank _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |