Create a new version of MAGIC; called Magic v2#24163
Create a new version of MAGIC; called Magic v2#24163leonerd wants to merge 2 commits intoPerl:bleadfrom
Conversation
|
Can it be called "sorcery"? |
f68b250 to
a332da2
Compare
|
A TODO list of items that still need addressing: (none) |
a332da2 to
f096dcf
Compare
|
The few TODO items notwithstanding, I think this is now justabout ready for a review; at least to get some more eyes on it and gain a rough feel for what people think of it. |
f096dcf to
70eeb05
Compare
|
In particular, two of these TODO items are really more questions for other people, as I don't have particularly good ideas: The
|
I don't care much what the actual numbers are, but they should have names, and there shouldn't be a 'latest' name visible outside of core. Perhaps the names could be functional:
but that could get silly. I don't see much point to using random numbers for versions so probably a simple sequence (1,2,3,4,...) is best A version outside of the implemented values should panic. (prevent someone doing 100 if we use 1,2,3..., or ~0U if we use a bitmask).
I don't think it needs to be tied to the perl version number - AFAICT this is for source compatibility, do I need to rewrite when I go from 5.44 to 5.46?
Probably perlguts, along with the older magic discussion. It might be worth splitting it perlguts up, but I don't know if you want to do that. |
70eeb05 to
d5cd494
Compare
|
@tonycoz Yes I think you're right, in that it shouldn't follow the perl version number, as then there would be many "pointless" bumps if there were new versions that didn't change the layout of the struct in any meaningful way. I also don't think a bitfield of "features" is all that useful - as you say it's not useful for there to be holes on it. I think I will just go with simple integers 1, 2, 3, ... Starting at 1, to avoid the "uninitialised as zero" problem. |
|
Actually, no. I will start at 2, because "magic v2 version 1" would be too confusing. "magic v2" is less v2, and more "not version 1" - if ever we hit a version 3, maybe we'd rename the flags to be "extended" magic or something. Though not to be confused with extmagic and the sv_magicext function from v1. Ugh. Naming is hard. Version numbers are hard too. |
15ba904 to
264b78e
Compare
That seems a reasonable first cut, I've moved it there and adjusted/expanded on some of the existing words. I think it does suggest that the entire "magic" section could be pulled out into a new "pod/perlmagic.pod" document. I don't think I will do that quite yet, but it would definitely be something to consider when we start expanding on the structure here by adding new abilities or whatever; those things would want more documentation anyway. |
|
Right then. I believe that's all my current TODO list sorted. :) |
tonycoz
left a comment
There was a problem hiding this comment.
Any sufficiently advanced technology is indistinguishable from ...
|
Thanks @tonycoz :) As this is quite a large change, with lots of additional docs and tests and so on, I'll still leave it a couple more days for folks to gather any additional comments or thoughts before merging it. |
8313af5 to
636bceb
Compare
|
I don't think we should merge this at this stage of the release cycle. There's little advantage to doing so (the first phase doesn't enable us to do anything we currently can't do), but there is a risk that we got interfaces wrong. It's probably better to merge this in 5.45.1, so we can merge the follow-up before 5.46 happens. |
636bceb to
4a10cf5
Compare
4a10cf5 to
5625cc0
Compare
5625cc0 to
dab9d58
Compare
The existing `MAGIC` and `MGVTBL` structures are insufficiently extensible, because they lack any embedded type information, or any version numbering by which new abilities can be added in a backwards-compatible way. Commit 6d97c86 managed to free a single bit in the `mg_flags` field; it is this bit that we use to indicate that the `MAGIC` structure refers to version 2 of Magic. The new structures are defined in a way that should be much easier to permit updates in future; primarily by the presence of a version number in the `ver` field, and the set of trigger functions in the `shape` field. In this way, we hope to be able to extend the abilities of magic in the future by adding new structure shapes as well as new trigger functions.
The existing
MAGICandMGVTBLstructures are insufficiently extensible, because they lack any embedded type information, or any version numbering by which new abilities can be added in a backwards-compatible way. Commit 6d97c86 managed to free a single bit in themg_flagsfield; it is this bit that we use to indicate that theMAGICstructure refers to version 2 of Magic.The new structures are defined in a way that should be much easier to permit updates in future; adding new structure shapes as well as new trigger functions to the various shapes entirely. In this way, we hope to be able to extend the abilities of magic in the future.
--
This PR is verymuch in "first stage" development, as I'm sure there's plenty of things that need discussion and adjustment before we want to actually merge it.