My idea was not that it should be exclusively based on the 'loose'
model, but rather that the loose model would be provided by all
interfaces, in addition to the constrained one.
So SvnCheckout could have it's port set by using setAttribute("port",
"123") (which would be provided by the top interface), or by using
setPort(123) (which would be provided by the SvnCheckout interface).
Rather sofisticated reflection or bytecode engineering is a problem the
moment it requires permission that might not be allowed in certain
situations (Applets).
HHmmm... but now that i think about it, we can have 2 interfaces, one
which is the parent one for all actions/services, and another one for
services that expose a 'loose' interface... What do you think ?
On Fri, 09 Dec 2005 14:41:00 +0100, "Mario Ivankovits" <[EMAIL PROTECTED]>
said:
> I am definitely against having generic interfaces. If I write programs I
> would like to compile my stuff and can be sure to have no syntax error
> in it.
>
> Having interfaces like
> setAttribute(String key, String value)
> is against my wishes.
>
> If the value provided is syntactical correct (e.g. setAttribute("port",
> "abd")) cant be checked during compile time, while
> SvnCheckout.setPort(123) can be checked.
> I am sure we find ways to call those services remotely without having
> all the classes on the client. e.g by providing a RemoteService object
> which uses reflection on the server side to configure the services then.
>
> The same idea I implemented in the *FileSystemConfigBuilder stuff. If
> you e.g. have to process settings from an xml-file you can use the
> DelegatingFileSystemObjectBuilder which uses (for sure rather
> sophisticated) reflection to call the type safe implementations the.
>
> ---
> Mario
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
