in reply to Remove a role from a Moose object

(I'm trying to understand what you are actually going to do with an object instance that dynamically modifies its interface.)

Can you provide more detail on how you are using the role 'Configurable'? I do not understand why it would be necessary or appropriate to add/remove a role on a specific object instance.

a) Are you using "$host->has_role('Configurable')" as a flag to determine whether $host is readonly or writeable?

b) Does 'Configurable' provide the setters and you remove the role to hide them in order to prevent write access?

c) ???

Replies are listed 'Best First'.
Re^2: Remove a role from a Moose object
by balachandran (Novice) on Nov 07, 2016 at 18:01 UTC
    The 'Configurable' role provides a bunch of methods that lets you modify some configuration files (ini and xml files). If a host is marked as read-only during the course of execution, then any attempt to configure that should result in an error.

    Now, to answer you questions

    a) the user checks  if ($host->configurable()) before using those methods. It is a syntactic sugar for has_role.

    b) Configurable provide getters/setters and a whole bunch of other methods. The epxectation is that the object should not expose any of those methods.

    c) What's the question ? I've no clue what '???' means.

    And as to why I am doing this, this(making nodes readonly) is quite a common scenario when you are working with a set of network devices acting together. Call it a cluster of nodes if you want. I am just trying to see if there is a simple way of achieving what I want. Thanks
[reply]
[d/l]

      I am pondering whether you are doing something extremely clever (and I fail to see the point) or whether you're just doing it wrong. The reason why I consider 'you are doing it wrong' is because all instances of a specific class are supposed to have the same interface.

      Typical approaches to solve your requirements would be:

      • define separate classes (e.g. 'host_Configurable' and 'Host_NonConfigurable'), where one provides setters and the other doesn't
      • always provide the setter-Methods (but silently ignore or violently die()/croak() if 'configurable()' is set to false)

      In your case I suggest the second approach since you indicated the readonly/readwrite status may change at some point.

[reply]
        Thanks, I am going with the second approach for now. croaking/confessing when configurable is false. Thanks again.
[reply]

In Section Seekers of Perl Wisdom