Ticket #918 (closed cage: done)

Opened 5 years ago

Last modified 5 years ago

Change handling of class_init functions

Reported by: NotFound Owned by: NotFound
Priority: minor Milestone:
Component: pmc2c Version: 1.4.0
Severity: low Keywords: deprecate
Cc: Language:
Patch status: Platform:

Description (last modified by NotFound) (diff)

The class_init functions from pmc and dynpmc are inserted in line into the generated class+init that does internal work. This way exposes undocumented variables to the user class_init, which is confusing.

The attached patch shows the proposed change: put the code in a static function and call that function from the generated class_init.

The only problem is that dynpmc from external modules or languages can still be using the now unneeded 'pass' variable, thus that change may need a deprecation cycle.

Attachments

class_init.patch Download (1.9 KB) - added by NotFound 5 years ago.

Change History

Changed 5 years ago by NotFound

Changed 5 years ago by NotFound

  • description modified (diff)
  • summary changed from Change handling of init_class functions to Change handling of class_init functions

Changed 5 years ago by bacek

+1 for idea. We just need consistent naming of "get_foo" vs "foo" method. May be "emit_foo_function" like "emit_class_init_function" is semantically clear enough?

Changed 5 years ago by NotFound

  • status changed from new to assigned
  • owner set to NotFound
  • component changed from none to pmc2c
  • type changed from RFC to cage
  • keywords deprecate added

Added deprecation notice in r41560

Changed 5 years ago by NotFound

Patch applied in r43710. Waiting for some more resting and feedback before removing the deprecation notice and closing the ticket.

Changed 5 years ago by NotFound

  • status changed from assigned to closed
  • resolution set to done

Removed deprecation notice in r44092, closing ticket.

Note: See TracTickets for help on using tickets.