The problem is that your statement is incorrect, and hence clearly not a trusim.

By way of illustration: if someone were designing a harness to prevent people from falling off rock-faces, would you require the designer to be well-versed in the finer points of General Relativity?

You need to be aware of the effects of gravity; you don't need to know about its internal implementation. You need to know that if you let go of a rope with nothing to support you, you will fall; you don't need to know that the reason why that happens is because space-time is curved around massive objects. The implications of gravity are that under certain circumstances it is unwise to let go of ropes; you need to know what those situations are; but the reason why gravity causes you to fall under those circumstances doesn't matter in the slightest. If God were to carry out some massive changes in the internal implementation of gravity such that it suddenly started working in a Newtonian rather than Einsteinian fashion, that wouldn't make the slightest difference to safety-harness design.

Needing to know about the consequences of implementation doesn'tin any way imply a need to know about implementation; indeed, if it did, OO in its current form could not exist, because for an object to understand another object's public interface behaviour would require it to be aware of the private details of how that behaviour is implemented: public behaviour is, after all, a consequence of private implementation.

I would think the simplest thing to do there is simply to look up the class by name.

Smalltalk syntax might be:

createInstanceOfClassNamed: aString

    | class |

    class := (Smalltalk at: aString asSymbol).
    ^class new

Another possibility would be to actually pass in the class itself as a parameter to the method:

createInstanceOfClass: aClass

    ^aClass new

You'd have to think a bit about where the class parameter came from, of course; but your string parameter must have come from somewhere too. If the string was a property on an object, then perhaps instead of storing a string you could store a reference to the class instead, or perhaps return the class as the result of a method which is implemented polymorphically (although the latter is starting to lead you into parallel inheritance hierachies, which are also usually not a good idea).

For your later example about the farm bureau website, that looks like you're using code to handle something which is really just data. You could perhaps have a class whose instances have two properties ("name" and "code") which correspond to the two strings in question. Any other object would then have a reference to an instance of that class rather than directly to one of the two strings, and you pick whichever is appropriate.

Or, if you really want to do a dynamic look-up for some reason, then hold the values in a database table for persistance, and use all the values in the table to populate a Dictionary when the application launches. (But I'm not altogether persuaded that really is what you want to do!)

Classes would be overkill; but it might well be reasonable to wrap that up in a method. An asBoolean method on the String class, perhaps:

asBoolean

    (#('y', 'yes', 'yeah', 'okay', 'yup', 'absolutely', 'go ahead', 'uh huh', 'yo') includes: self asLowercase) ifTrue: [^true].
    (#('n', 'no', 'nope', 'i wouldn''t', 'definitely not', 'uh uh', 'no way') includes: self asLowercase) ifTrue: [^false].
    ^nil

As flumpy goes on to say, it might very well be reasonable to have a method or potentially even a whole class dedicated to obtaining a yes or no answer. In my old Smalltalk application, for example, there's a MessageBox class. That has a class method called #confirm: (which takes a string as argument). That brings up a messagebox with the appropriate text, the title "please confirm", the question-mark icon, and buttons marked Yes and No; it returns a boolean. So you can do:

(MessageBox confirm: 'Are you sure?') ifFalse: [^#cancelled]

You must have a lot of straw lying around, if you can afford to make such large men out of it. :lol:
You have this exceedingly irritating tendency to quote something, disagree with it, while utterly ignoring pieces of the very same post that preempt this exact reason for disagreement. In this case in particular with your cute straw man suffering the effects of gravity, it's just plain silly. It's unclear to me if you're actually interested in "usefully advancing the discussion" and stop "scoring points" as you exhorted me to do earlier, given that you seem bent on taking my words to be the stupidest possible while simultaneously ignoring the pieces that explain why your objection is incorrect. But as you said in another thread: life is too short.


Oh, how utterly silly of me to fail to mention that you should "encapsulate the process". Oh wait. :thinking: I guess you didn't read the whole post again? Or maybe I didn't use the magic word "method". :wink:

Incidentally, modifying asBoolean for all strings to behave like that, especially the way you showed, seems shockingly wrong to me, but oh well.

Girls, girls, you're both very pretty…

Yes, and you're hilarious, flumpy. :lol:

Only when covered in jam and tied to an elephant in a clowns outfit, I'm afraid…