Component problem

I have a problem with Component class in iphone.
I am trying to access any custom script and assigning to a variable of type Component
such as:

var AnyScript:String;
var a :Component = transform.GetComponent(AnyScript);
a.enabled=true;
a.hypo = 1235; // script has a visible parameter hypo

The problem is a.enabled and a.hypo works on pc and mac but when conversion to iphone, it doesn’t work. I get errors.

Please suggest any way to fix that using the current way. I am guessing if keyword “as” or typecast could help but I am clueless on how to do that. Infact even if I do it how do i access those visible parameters

I’m a fan of strong typing, since it solves these sorts of problems. I’m guessing the iphone doesn’t like the fact that Component doesn’t have these attributes. I’m also guessing you have multiple scripts with “enabled” and “hypo” attributes on them, right? If this is the case, then there’s a good chance that these scripts are the same type of thing, so you can use inheritance. For example, you have a “Man” script and a “Woman” script that each have enabled and hypo scripts. Create a new script called “Human”, tell the Man and Woman scripts that they inherit from “Human” instead of MonoBehavior, and then say “var a : Human = …”

i see your point…problem is that i began my program with functional programming for rapid prototyping. Most of the similar scripts have update function so even if i can change them to class without monobehaviour inheritance…i will have to implement another class that inherits monobehaviour and now if i do that i will have convert all those scripts to classes. From my understanding, since all scripts have only a few variables and function in common, i will have to keep classifying the type of behaviour…infact keep narrowing it down to use it, when instead i can simply attach a custom script and let it do its thing. Can you suggest any alternative at this point.

Its very important for me know where can i draw the line between scripts and OO programming, can you suggest to what extent should i use both. Heh and also since you say strong typing solves these sorts of problem…can you emphasize on that, i am a young programmer and i really need to know these things so i can give proper base to my games for development sake.

i see your point…problem is that i began my program with functional programming for rapid prototyping. Most of the similar scripts have update function so even if i can change them to class without monobehaviour inheritance…i will have to implement another class that inherits monobehaviour and now if i do that i will have convert all those scripts to classes. From my understanding, since all scripts have only a few variables and function in common, i will have to keep classifying the type of behaviour…infact keep narrowing it down to use it, when instead i can simply attach a custom script and let it do its thing. Can you suggest any alternative at this point.

Its very important for me know where can i draw the line between scripts and OO programming, can you suggest to what extent should i use both. Heh and also since you say strong typing solves these sorts of problem…can you emphasize on that, i am a young programmer and i really need to know these things so i can give proper base to my games for development sake.

Although I’m new to Unity, I’ve been a professional programmer for almost 10 years. I can tell you that OO is the way to go if you want to do complicated things. The more scripts you add to an object, the more complicated it gets, especially after you’ve been working on it for months. If you declare the class of every variable you’re using, then you always know what your working with, so you don’t have to get type mismatch runtime errors, you don’t have to check for classes to avoid those errors, and your code editor can help you more intelligently. Ctrl+Space will make you type code about 2x as fast.

In this case, Human would inherit from MonoBehavior, so the Man/Woman classes would inherit Update from their parent class Human, and would have to override it. Refactoring your code is a pain, but it makes it more maintainable. I’ve worked on plenty of projects where people coded for years without refactoring their code at all, and it takes so much longer to get anything done, and there come things that just can’t be done with something unless it gets refactored.

And while you’re refactoring, another thing to consider is that C# gives you more control and access to built-in C# classes that aren’t always there in Unity’s version of JS. Plus if you ever want to do any programming outside of Unity, C# is a real programming language, and Unity’s scripting isn’t.