You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
these reflectors apply to ports and errors, which are comparable, object-like structures which are efficiently implemented.
this is nothing more (or less) than a plea for consistency and regularity in the language in this respect
with gobs, the reflectors should yield the "owner" word/value only if set; and they should yield at most one of the draw/text/etc. words and/or values, as a very efficient way of checking which one of the five is set, if any
There is only so much uniformity we can get, since different datatypes have different meanings. Even the existing reflectors don't apply to all of the types that other reflectors apply to. Still, let's give it a shot, limited to just the reflectors you mention.
None of the reflectors should apply to image! - images are not object-like or function-like. Even TO-BLOCK doesn't convert an image to a block, it just wraps it.
As for events and gobs, since REFLECT is an action these wouldn't necessarily hurt to support. It depends on whether we want to pretend that these types are object-like, the way we do with the map! type. They aren't a part of any-object! since they can't be bound, but neither is map!.
Rebolbot commented on May 18, 2009:
Submitted by:Carl
My comments:
Some datatypes are "pseudo-objects" that allow special selectors. For example, date! and time! allow date/year, date/month, etc.
It seems reasonable that some level of reflection regarding such selectors could be useful for debugging/IDE/educational reasons.
For example, if I want to know what selectors can be used on a date, a reflector could provide that information.
Rebolbot commented on Feb 16, 2010:
Submitted by:henrikmk
I'd say it's nearly essential to allow reflection on gob!s and event!s to figure out how VID3.4 is put together and for general exploration. Otherwise document the entire structure of gob! and event!.
Submitted by: meijeru
these reflectors apply to ports and errors, which are comparable, object-like structures which are efficiently implemented.
this is nothing more (or less) than a plea for consistency and regularity in the language in this respect
with gobs, the reflectors should yield the "owner" word/value only if set; and they should yield at most one of the draw/text/etc. words and/or values, as a very efficient way of checking which one of the five is set, if any
Imported from: CureCode [ Version: alpha 54 Type: Wish Platform: All Category: n/a Reproduce: Always Fixed-in:none ]
Imported from: metaeducation#829
Comments:
Submitted by: BrianH
There is only so much uniformity we can get, since different datatypes have different meanings. Even the existing reflectors don't apply to all of the types that other reflectors apply to. Still, let's give it a shot, limited to just the reflectors you mention.
None of the reflectors should apply to image! - images are not object-like or function-like. Even TO-BLOCK doesn't convert an image to a block, it just wraps it.
As for events and gobs, since REFLECT is an action these wouldn't necessarily hurt to support. It depends on whether we want to pretend that these types are object-like, the way we do with the map! type. They aren't a part of any-object! since they can't be bound, but neither is map!.
Submitted by: Carl
My comments:
Some datatypes are "pseudo-objects" that allow special selectors. For example, date! and time! allow date/year, date/month, etc.
It seems reasonable that some level of reflection regarding such selectors could be useful for debugging/IDE/educational reasons.
For example, if I want to know what selectors can be used on a date, a reflector could provide that information.
Submitted by: henrikmk
I'd say it's nearly essential to allow reflection on gob!s and event!s to figure out how VID3.4 is put together and for general exploration. Otherwise document the entire structure of gob! and event!.
The text was updated successfully, but these errors were encountered: