groovy

refactor void GroovyObject.setMetaClass() {} to something like Object GroovyObject.become(MetaClass) {}

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

So that we can coerce one object into another, but returning a new object reference in case we need to do some bytecode magic etc

Issue Links

depends upon

Task - A task that needs to be done. GROOVY-2503 MOP 2.0 design inflluencing issues

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.
duplicates

Improvement - An improvement or enhancement to an existing feature or task. GROOVY-960 Change the MetaClass methods to not be bean properties

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is related to

Improvement - An improvement or enhancement to an existing feature or task. GROOVY-960 Change the MetaClass methods to not be bean properties

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
John Wilson added a comment -

I think this is intrinsically a good idea. Changing the MetaClass of a live object in a muti threaded environment is not a healthy thing to do.

A consequence of this (I think) is that all Groovy Objects have to be Clonable so GroovyObject should extend Clonable.

If we are making breaking changes to GroovyObject then we should take the opportunity to align the method signatures of invokeMethod and get/setProperty with the new MOP.

Should we add get/setAttribute?

Show
John Wilson added a comment - I think this is intrinsically a good idea. Changing the MetaClass of a live object in a muti threaded environment is not a healthy thing to do. A consequence of this (I think) is that all Groovy Objects have to be Clonable so GroovyObject should extend Clonable. If we are making breaking changes to GroovyObject then we should take the opportunity to align the method signatures of invokeMethod and get/setProperty with the new MOP. Should we add get/setAttribute?
Hide
Permalink
Guillaume Laforge added a comment -

I think that makes sense to add get/setAttribute() if we're to change GroovyObject a little.
That's the best opportunity to make that change.
Otherwise it'll be too late...

Show
Guillaume Laforge added a comment - I think that makes sense to add get/setAttribute() if we're to change GroovyObject a little. That's the best opportunity to make that change. Otherwise it'll be too late...
Hide
Permalink
John Wilson added a comment -

I think the method signature should be GeoovyObject become(MetaClass)

i.e. it us guaranteed to return a GroovyObject not just an Object

Show
John Wilson added a comment - I think the method signature should be GeoovyObject become(MetaClass) i.e. it us guaranteed to return a GroovyObject not just an Object
Hide
Permalink
John Wilson added a comment -

If we change setMetaClass then we might as well change getMetaClass at the same time

Show
John Wilson added a comment - If we change setMetaClass then we might as well change getMetaClass at the same time
Hide
Permalink
blackdrag blackdrag added a comment -

The MOP 2.0 does not add a get or setMetaClass method directly on the class anymore. With that the basic reason for this reason becomes invalid

Show
blackdrag blackdrag added a comment - The MOP 2.0 does not add a get or setMetaClass method directly on the class anymore. With that the basic reason for this reason becomes invalid

People

  • Assignee:
    blackdrag blackdrag
    Reporter:
    james strachan
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: