Wikifunctions:Type proposals/Wikifunctions object reference

Done Implemented as Wikifunctions object reference (Z96) --DVrandecic (WMF) (talk) 14:04, 27 August 2026 (UTC)

Summary

Follow the pattern used for the various Wikidata references (Z6091, for example) to provide safe (non-dereferencing) references to Wikifunctions objects as well.

Uses

• Prevent the automatic de-referencing of references extracted from Wikifunctions objects (by Z803, for example).
• Allow more straightforward and efficient comparison of types. For example:
  • type of object (Z16829) (or an equivalent) could return a Wikifunctions object reference rather than a fully expanded type object
  • Type identity (Z19077) extracts a type’s Z4K1 but this is currently expanded back into the referenced type, making type comparisons inefficient
  • same Type (Z19084) one Python implementation explicitly compares only Z4K1 values, but the types and their references have already been fully expanded by the orchestrator
  • “same type reference” would be more efficient, simplifying to string equality (Z866)
  • Object has this Type (Z19352)
  • Typed list has the same Object for its Type (Z18636)
  • “type is one of” could be implemented with contains (Z12696)
• Simplify search string functions like String for function signature search (Z22973), allowing the type reference to be entered as a string, where known.
• Consistent approach across Wikidata and Wikifunctions references, perhaps allowing objects like types to be used in enumerations.

Structure

Like Z6091, Wikifunctions object reference would be a wrapped string, with the string having the form of a Z9.

Example values

A reference to the type Z6001

{   "type": "Wikifunctions object reference", "value": "Z6001" }

{   "Z1K1": "Z6090", "Z6090K1": "Z6001" }

Validator

The validator ensures that:

• The string value is a valid Z9

Identity

Two Wikifunctions object references are the same if their string values are equal.

A Wikifunctions object reference is equivalent to a Wikifunctions object if there is a Z2 whose Z2K1 is the same as the value of the Wikifunctions object reference and that Z2 has a value for its Z2K2 that is equivalent to the Wikifunctions object.

Converting to code

Python

Converts in the same way as Z6091 but there might be an explicit Z46 and Z64, if the type does not need to be built in.

JavaScript

Converts in the same way as Z6091 but there might be an explicit Z46 and Z64, if the type does not need to be built in.

Display function

Should be a simple string but can be displayed in the interface as the label of the referenced object (as currently) or as a link to the referenced object (as with Wikidata references)

Read function

Could be a simple string but the use of an object selector should be an option

Alternatives

The alternative is to make Z9 behave properly, but its behaviour would still be inconsistent with Wikidata reference objects, which will be more familiar to most users.

The validator could also ensure that there is a Z2 whose identity is the same string, but this would be inconsistent with the current approach for Wikidata references.

Z6090 is used here as an example, but it would be nice if we could actually use that value,

Comments

•  Support as proposer. --GrounderUK (talk) 12:14, 10 April 2025 (UTC)
•  Oppose, name should be "Persistent object reference." Willing to support if this is fixed. Feeglgeef (talk) 11:20, 11 April 2025 (UTC)

  Without defending the proposed English label, I would object to your alternative suggestion because a reference to a persistent object is just a Reference (Z9). The proposal is for a wrapped ZID string, aligned to Key reference (Z39) and Wikidata item reference (Z6091) etc, which is where “reference” came from, but they are all probably better described as “identifier”. GrounderUK (talk) 11:29, 14 July 2026 (UTC)

•  Support with either name. I'm starting to understand the deeper need for things like this. This might be an important precursor to lightweight enums of ZIDs, which I've now spotted some uses for. --99of9 (talk) 00:16, 26 September 2025 (UTC)

  Thanks. I’ve referenced this proposal in phab:T405837, specifically for converting a string reference (“ZID”) to a Reference (Z9). GrounderUK (talk) 14:32, 27 September 2025 (UTC)

  Further, I support making this a generic Type, as proposed by the team. This will help limit the valid values to ZIDs with certain types where needed. --99of9 (talk) 04:05, 17 July 2026 (UTC)

  Sorry, are you referring to phab:T405810 or something else? As with Z6091, I would expect this proposed type to be a standard persistent type and enumerations to provide the limitations. I don’t object to limitations simply by type of object, but I haven’t seen that proposed anywhere. GrounderUK (talk) 08:32, 17 July 2026 (UTC)

  See the recent newsletter. That's why I was grilling you yesterday. --99of9 (talk) 08:37, 17 July 2026 (UTC)

  Ah, right. Thanks. Somehow that passed me by! If we adopt such an approach, we should probably call it “Typed reference”. If its type is Z1, I would expect it to behave just like the proposed type, except the ZID’s key would be K1. We would need to address phab:T417266 to get acceptable usability, I think (I’m sure there’s a ticket for nested lists too, but I haven’t tracked it down, unless I’m just thinking about phab:T390786). GrounderUK (talk) 11:18, 17 July 2026 (UTC)

  Maybe "Typed Wikifunctions Item Reference"? I will continue to call it "ZID" no matter what ;-) --99of9 (talk) 14:08, 17 July 2026 (UTC)

  Since a generic type can sometimes be a bit heavy weight, and the whole point of this type is to be as lightweight as possible, what about the idea of having two keys, both strings, one for the type and one for the object? --DVrandecic (WMF) (talk) 08:00, 3 August 2026 (UTC)

  I don't think I would use the type very often. The main benefit I see of associating it with a type is to constrain the valid inputs into the argument of a function. So if that makes it too heavyweight then I think I'd skip it entirely. When specifying a ZID, I'd prefer not to have to type in a Type as well. I'm always keen to hear what @GrounderUK has to say on issues like this. --99of9 (talk) 10:47, 3 August 2026 (UTC)

  I don’t have a view on whether a generic type is heavyweight compared with a static type. My concern with appending the referenced object’s type as a string is that the misbehaviour of ZID strings is part of the problem that the proposed type is intended to address. Introducing another ZID string for the type therefore seems slightly at odds with that goal. Logically, the type-ZID would itself be an instance of the proposed type rather than a String (Z6).

  My inclination would be to do the simplest thing and leave the referenced object’s type implicit (as originally proposed). If a case can be made for a typed variant – to constrain function arguments, for example – then I think we should consider that separately. Whether such a variant would have a generic type or wrap the type-ZID, I’m not sure; that would depend on the proposed use cases. @99of9 GrounderUK (talk) 08:57, 5 August 2026 (UTC)

  My current favourite use cases are:

  • Argument 2 of monolingual text as HTML with lang, col, ✏️🔧links (Z37464) where constraining to be a config (searchable?) would be nice, but it's a niche kind of thing that only functioneers will need to deal with.
  • Lightweight (unordered) enums of this new type where we can define a group of functions which all do the same kind of thing, and can be selected from. The type checking is unnecessary here because they would be carefully chosen when setting up the enum group, which then would be a defined type anyway, so the subsequent argument selector would work.

  So, unless @DVrandecic (WMF) or the team sees deeper needs, let's just go with the bare original proposal? --99of9 (talk) 13:12, 5 August 2026 (UTC)

  Yes, but unless there are UI changes, I don’t see how type selection ends up being a constraint. For function arguments, I think we’d have to create a wrapper function that returns the ZID argument as a wrapped string iff the referenced object has the specified type (and an error otherwise). The function signature would require a ZID object (“Wikifunctions Object Reference”) and the wrapper function would have that return type, as well as an argument of that type. That’s effectively a filter (like pass object if predicate is true (Z31065)), so we could have it also accept a predicate function (like Object has this Type (Z19352)) or make it specific to type(s). An example call, using Reference from ZID string (Z1 context: try Z869) (Z29102), which validates that the object identified by the literal string has the specified type: Configuration of functions for given languages (Z14294). GrounderUK (talk) 15:28, 5 August 2026 (UTC)

  I'm expecting UI changes eventually. Like we have chips to search for QIDs or LIDs. There's no rush on this until lots of AW users see arguments of this type. --99of9 (talk) 22:11, 5 August 2026 (UTC)

•  Support --Ameisenigel (talk) 08:25, 12 May 2026 (UTC)
•  Support--So9q (talk) 14:09, 16 July 2026 (UTC)
•  Support -- JhowieNitnek (talk) 16:21, 10 August 2026 (UTC)

Might make fixing Z828 easier

The built-in function Z828 has issues described in phab:T366246 and phab:T366403 with improvements suggested in phab:T366459. Using a wrapped string for the required object reference rather than a quoted reference would probably make these issues easier to resolve. GrounderUK (talk) 22:12, 10 April 2025 (UTC)

Also Error strings

If you’ve ever wondered why your error-message strings just vanish when they contain only a ZID, it’s because the ZID is taken to be a Reference, de-referenced to an object and then dropped for not being a string. This would still happen if a Wikifunctions object reference/identifier were unwrapped and it would also be dropped as a non-string if it were not. We should probably raise a Phabricator ticket for this, but it might be better deferred if unwrapping/reducing to a string could be a general feature of Wikifunctions.Error. GrounderUK (talk) 15:33, 16 July 2026 (UTC)

Implementation started

We started implementing this Type as originally suggested, just with a single key string. As this is potentially becoming a basic type, we moved it to the built-in space, and so it needs to be deployed through code changes. You can follow the implementation here. --DVrandecic (WMF) (talk) 07:08, 13 August 2026 (UTC)