[Seaside] unused methods

Frank Shearar frank.shearar at angband.za.org
Sun Apr 19 19:09:14 UTC 2009


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.
>   
How difficult would it be to move these unused methods to a new package 
- 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


More information about the seaside mailing list