Template talk:Navbox unrealscript - Revision history

00zX at 04:00, 17 May 2010

2010-05-17T04:00:09Z

00zX at 03:59, 17 May 2010

2010-05-17T03:59:22Z

Wormbo: oh, I definitely am

2010-05-16T18:22:35Z

oh, I definitely am

00zX at 16:49, 16 May 2010

2010-05-16T16:49:44Z

Azrael: New page:

2008-05-05T11:39:14Z

New page:

New page

← Older revision		Revision as of 04:00, 17 May 2010
Line 3:		Line 3:
	:Yes, I am very sure about that. "Self" acts very much like a "magically-typed" variable pointing to the object executing the current code. Most notably can you use "Self" as standalone keyword, unlike default, super or global. Calling it an object literal is as close to reality as you can get, because you can also do stuff like <code>Material'WhiteTexture'.Class</code>, which most likely returns the value <code>class'Texture'</code> in UE1/2 games. Doing stuff like Self.Name is identical to just Name, unless you declare local variables that hide the class variables. And if you look at UnrealScript bytecode, you will find that, unlike Super, Global and Default, access via "Self" has the same format as access via an object reference returned by a variable or function call, with Self being represented by a single-byte token like True, False, 0, 1 and None. —[[User:Wormbo\|Wormbo]] 18:22, 16 May 2010 (UTC)		:Yes, I am very sure about that. "Self" acts very much like a "magically-typed" variable pointing to the object executing the current code. Most notably can you use "Self" as standalone keyword, unlike default, super or global. Calling it an object literal is as close to reality as you can get, because you can also do stuff like <code>Material'WhiteTexture'.Class</code>, which most likely returns the value <code>class'Texture'</code> in UE1/2 games. Doing stuff like Self.Name is identical to just Name, unless you declare local variables that hide the class variables. And if you look at UnrealScript bytecode, you will find that, unlike Super, Global and Default, access via "Self" has the same format as access via an object reference returned by a variable or function call, with Self being represented by a single-byte token like True, False, 0, 1 and None. —[[User:Wormbo\|Wormbo]] 18:22, 16 May 2010 (UTC)

−	::Fair enough, I was just curious as to your reasonings. I havent seen the bytecode because I rarely pay attention on that level, I could however. What you are saying does makes sense now Ive heard it and Im pretty sure this relationship between Self and True/False, 1/0 and None has been mentioned in other discussions we've had. No doubt you could try to use name or class but they are ambiguous so I always use self. object reference prefix as it explains what that variable does more precisely. As one example (going alittle off the topic) class = class'class', is actually incorrect self on the other hand gives a frame of reference (like super/global/default) which is why I thought what I did. To extent this function that sets class = class'class' and call super on it which class are we then talking about? SuperClass.Function() or Class.Function() using self would cause SuperClass.Function() to always call, SuperClass.Class = class'class' wouldnt it ! Class.Class = class'class'	+	::Fair enough, I was just curious as to your reasonings. I havent seen the bytecode because I rarely pay attention on that level, I could however. What you are saying does makes sense now Ive heard it and Im pretty sure this relationship between Self and True/False, 1/0 and None has been mentioned in other discussions we've had. No doubt you could try to use name or class but they are ambiguous so I always use self. object reference prefix as it explains what that variable does more precisely. As one example (going alittle off the topic) class = class'class', is actually incorrect self on the other hand gives a frame of reference (like super/global/default) which is why I thought what I did. To extent this function that sets class = class'class' and call super on it which class are we then talking about? SuperClass.Function() or Class.Function() using self would cause SuperClass.Function() to always call, SuperClass.Class = class'class' wouldnt it ! Class.Class = class'class' --[[User:00zX\|00zX]] 04:00, 17 May 2010 (UTC)

← Older revision		Revision as of 03:59, 17 May 2010
Line 2:		Line 2:

	:Yes, I am very sure about that. "Self" acts very much like a "magically-typed" variable pointing to the object executing the current code. Most notably can you use "Self" as standalone keyword, unlike default, super or global. Calling it an object literal is as close to reality as you can get, because you can also do stuff like <code>Material'WhiteTexture'.Class</code>, which most likely returns the value <code>class'Texture'</code> in UE1/2 games. Doing stuff like Self.Name is identical to just Name, unless you declare local variables that hide the class variables. And if you look at UnrealScript bytecode, you will find that, unlike Super, Global and Default, access via "Self" has the same format as access via an object reference returned by a variable or function call, with Self being represented by a single-byte token like True, False, 0, 1 and None. —[[User:Wormbo\|Wormbo]] 18:22, 16 May 2010 (UTC)		:Yes, I am very sure about that. "Self" acts very much like a "magically-typed" variable pointing to the object executing the current code. Most notably can you use "Self" as standalone keyword, unlike default, super or global. Calling it an object literal is as close to reality as you can get, because you can also do stuff like <code>Material'WhiteTexture'.Class</code>, which most likely returns the value <code>class'Texture'</code> in UE1/2 games. Doing stuff like Self.Name is identical to just Name, unless you declare local variables that hide the class variables. And if you look at UnrealScript bytecode, you will find that, unlike Super, Global and Default, access via "Self" has the same format as access via an object reference returned by a variable or function call, with Self being represented by a single-byte token like True, False, 0, 1 and None. —[[User:Wormbo\|Wormbo]] 18:22, 16 May 2010 (UTC)
		+
		+	::Fair enough, I was just curious as to your reasonings. I havent seen the bytecode because I rarely pay attention on that level, I could however. What you are saying does makes sense now Ive heard it and Im pretty sure this relationship between Self and True/False, 1/0 and None has been mentioned in other discussions we've had. No doubt you could try to use name or class but they are ambiguous so I always use self. object reference prefix as it explains what that variable does more precisely. As one example (going alittle off the topic) class = class'class', is actually incorrect self on the other hand gives a frame of reference (like super/global/default) which is why I thought what I did. To extent this function that sets class = class'class' and call super on it which class are we then talking about? SuperClass.Function() or Class.Function() using self would cause SuperClass.Function() to always call, SuperClass.Class = class'class' wouldnt it ! Class.Class = class'class'

← Older revision		Revision as of 18:22, 16 May 2010
Line 1:		Line 1:
	Are you sure about that [[User:Wormbo\|Wormbo]]? Self.Function() if the function is declared private/protected is much the same as Global/Super.Function(). Self.Variable is the variable is declared private/protected is much the same as Default.Variable. Though Self is not limited to these cases, it can be used also as in Self.Class, Self.Name, Self.Class.Name. Anyways just curious as to why it only gets the narrow Object Literal specification when obviously it does more then some specifiers. --[[User:00zX\|00zX]] 16:49, 16 May 2010 (UTC)		Are you sure about that [[User:Wormbo\|Wormbo]]? Self.Function() if the function is declared private/protected is much the same as Global/Super.Function(). Self.Variable is the variable is declared private/protected is much the same as Default.Variable. Though Self is not limited to these cases, it can be used also as in Self.Class, Self.Name, Self.Class.Name. Anyways just curious as to why it only gets the narrow Object Literal specification when obviously it does more then some specifiers. --[[User:00zX\|00zX]] 16:49, 16 May 2010 (UTC)
		+
		+	:Yes, I am very sure about that. "Self" acts very much like a "magically-typed" variable pointing to the object executing the current code. Most notably can you use "Self" as standalone keyword, unlike default, super or global. Calling it an object literal is as close to reality as you can get, because you can also do stuff like <code>Material'WhiteTexture'.Class</code>, which most likely returns the value <code>class'Texture'</code> in UE1/2 games. Doing stuff like Self.Name is identical to just Name, unless you declare local variables that hide the class variables. And if you look at UnrealScript bytecode, you will find that, unlike Super, Global and Default, access via "Self" has the same format as access via an object reference returned by a variable or function call, with Self being represented by a single-byte token like True, False, 0, 1 and None. —[[User:Wormbo\|Wormbo]] 18:22, 16 May 2010 (UTC)

← Older revision		Revision as of 16:49, 16 May 2010
Line 1:		Line 1:
−	~~<!-- this~~ is just ~~filler~~ to ~~get this page off~~ the ~~Wanted Pages list~~. -->	+	Are you sure about that [[User:Wormbo\|Wormbo]]? Self.Function() if the function is declared private/protected is much the same as Global/Super.Function(). Self.Variable is the variable is declared private/protected is much the same as Default.Variable. Though Self is not limited to these cases, it can be used also as in Self.Class, Self.Name, Self.Class.Name. Anyways just curious as to why it only gets the narrow Object Literal specification when obviously it does more then some specifiers. --[[User:00zX\|00zX]] 16:49, 16 May 2010 (UTC)