Difference between revisions of "Talk:LlDetectedName"

From Second Life Wiki
Jump to navigation Jump to search
 
(One intermediate revision by one other user not shown)
Line 2: Line 2:
[[User:Tali Rosca|Tali Rosca]] 00:13, 5 November 2009 (UTC)
[[User:Tali Rosca|Tali Rosca]] 00:13, 5 November 2009 (UTC)
: I took a slightly different tack and spelled out the events where they ''do'' work. Does that work for you? --[[User:Viktoria Dovgal|Tori]] 03:27, 5 November 2009 (UTC)
: I took a slightly different tack and spelled out the events where they ''do'' work. Does that work for you? --[[User:Viktoria Dovgal|Tori]] 03:27, 5 November 2009 (UTC)
== The name of attribute ==
I just wonder why its attribute name is "item" though other llDetected* articles use "number". -- [[User:Mako Nozaki|Mako]] 16:51, 13 October 2012 (PDT)
:Quick answer: "You really don't want to know, just change it. To observe the debate is to be trapped by it."
:'''Possibilities:'''
:# Nobody bothered to standardize this parameter name.
:# Factions could not agree on a standardized name.
:# Or one of the factions put forth the notion that "A foolish consistency is the hobgoblin of little minds" and it derailed things.
:'''Reality:'''
:It's a little of all of the above. The people who did bother to try and standardize the parameter names got distracted and bogged down by the later possibilities.
:Of the possibilities the third I find the most interesting as it epitomizes one of the struggles of the documentation. On the one hand, having things be consistent and obviously interlinked builds connections in the mind of the reader about how functions share functionality. However by using the same descriptions however we reduce the amount of information we are actually conveying. By having different descriptions of the same thing, it allows the reader to triangulate on the idea, and whittle it down to it's core. So we find ourselves at an impasse, standardization results in not enough information being conveyed about a group of functions, dissimilarity aids in understanding but obscures the grouping.
:I have a partial workaround for this problem in place but I haven't documented it and I'm not happy with it yet.
:When parameter name standardization has come up, it's been a contentious topic. People don't agree on what they should be standardized to or even if they should be standardized at all.
:It's not that nobody bothered to standardize the parameter names, the tempest in the teacup dissuaded them.
:But carry on, you can change it. I don't think anyone really cares about the name of this parameter. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 19:41, 13 October 2012 (PDT)

Latest revision as of 18:41, 13 October 2012

It may be worth mentioning explicitly in the Specification section that the llDetected... family does not yield useful data in listens, since that seems to be a common gotcha. Tali Rosca 00:13, 5 November 2009 (UTC)

I took a slightly different tack and spelled out the events where they do work. Does that work for you? --Tori 03:27, 5 November 2009 (UTC)

The name of attribute

I just wonder why its attribute name is "item" though other llDetected* articles use "number". -- Mako 16:51, 13 October 2012 (PDT)

Quick answer: "You really don't want to know, just change it. To observe the debate is to be trapped by it."
Possibilities:
  1. Nobody bothered to standardize this parameter name.
  2. Factions could not agree on a standardized name.
  3. Or one of the factions put forth the notion that "A foolish consistency is the hobgoblin of little minds" and it derailed things.
Reality:
It's a little of all of the above. The people who did bother to try and standardize the parameter names got distracted and bogged down by the later possibilities.
Of the possibilities the third I find the most interesting as it epitomizes one of the struggles of the documentation. On the one hand, having things be consistent and obviously interlinked builds connections in the mind of the reader about how functions share functionality. However by using the same descriptions however we reduce the amount of information we are actually conveying. By having different descriptions of the same thing, it allows the reader to triangulate on the idea, and whittle it down to it's core. So we find ourselves at an impasse, standardization results in not enough information being conveyed about a group of functions, dissimilarity aids in understanding but obscures the grouping.
I have a partial workaround for this problem in place but I haven't documented it and I'm not happy with it yet.
When parameter name standardization has come up, it's been a contentious topic. People don't agree on what they should be standardized to or even if they should be standardized at all.
It's not that nobody bothered to standardize the parameter names, the tempest in the teacup dissuaded them.
But carry on, you can change it. I don't think anyone really cares about the name of this parameter. -- Strife (talk|contribs) 19:41, 13 October 2012 (PDT)