Category talk:LSL Flow Control

LSL Prefix

Question: Does this category need the LSL prefix. SignpostMarv Martin 09:47, 23 February 2007 (PST)

Turns the question around: Why doesn't this category need the LSL prefix.

It comes down to aesthetics. There aren't any technical reasons. When looking at the category list it makes it easy to find LSL categories. Searching for LSL categories is difficult. It makes enumeration easier. Strife Onizuka 10:01, 23 February 2007 (PST)

1. LSL-specific categories should be listed under Category:LSL
2. Enumeration ?
3. If LSL-specific categories were listed under Category:LSL, and you were looking for LSL stuff you'd go there first- would the LSL prefix need to be there ?

SignpostMarv Martin 14:30, 23 February 2007 (PST)

Aesthetics and ease-of-use/maintainability.

1. I was considering making a Meta-Category for LSL. Wanted to get a better handle on the categories before I did so though. Not keen on moving content and renaming category pages (you can't move category pages; you have to edit them). Categorizing everything and writing category pages was my next project. After that constants. While it could be a good thing I don't feel the need to do it myself.
2. It plays into building a meta-category. See below.
3. Yes and no. How would you go about building it? Without the LSL prefix, how would you know which categories to add without going through them all. And if a new LSL specific category were created, would you be able to easily tell by looking at the category list? Having LSL as a prefix is a maintainable solution.

It makes editing easier and it's no uglier then having "Category:" before it. What's the harm in a little more prefix?

Strife Onizuka 16:49, 23 February 2007 (PST)

I think we can whittle this down to:

• If we don't make a root "LSL" category over at Category:LSL, keep the prefix (for the reasons you've said)
• If we do make a root "LSL" category, remove the prefix as it would be superfluous and annoying to see a bunch of "LSL" prefixes where they're not needed (LSL Style Guide etc being obvious exceptions)

SignpostMarv Martin 18:23, 23 February 2007 (PST)

*back on topic* As you point out with LSL Style Guide, having the LSL prefix makes sense there. Likewise it makes sense here, as this is a category of flow control for LSL exclusively (it's in the LSL Header), same with LSL Functions and LSL Events. Strife Onizuka 09:17, 24 February 2007 (PST)

I'm kinda 50-50 on the LSL prefix here

• It's the Flow Control for LSL
• What other Flow Control would we be talking about ?

SignpostMarv Martin 13:50, 24 February 2007 (PST)

*me nods in agreement* I'm more on the side of caution. Better to be prepared for the future where we might be defining another language on the wiki IMHO. Strife Onizuka 01:56, 26 February 2007 (PST)

I thought the consensus was to edit now, disambiguate later.

Flow Control itself is a category. It can cover Flow Control in any language. When, and only when Second Life supports other languages, should we create the sub category Category:LSL Flow Control. Currently, it's a given that articles be LSL-centric.

SignpostMarv Martin 06:47, 26 February 2007 (PST)

It's a balancing act between 'disambiguate' and 'most obvious name'. What is obvious is in the eye of the beholder. Strife Onizuka 02:21, 1 March 2007 (PST) PS: could be about packet flow control.

User defined functions

A couple of line about User-defined functions are missing here. Some readers may already have a clue about subroutines and functions i.g. and may learn how to use them in their scripts by browsing samples codes or "return" keyword page. However, it would be fine to have some explanations here about it, adding for example some precisions like "User-defined function has to be coded outside any state block" and words about return values. Do you think it is the right place to add that ? -- Forest Klaar

I'm not really sure where the right place to post something like that. The fit for it being on this category page isn't a good one but it's as a good a place as any. A slightly better page would be Functions a dedicated article would make sense too (linked from Functions article). Thanks for reminding me about that limitation. -- Strife Onizuka 13:47, 7 May 2007 (PDT)