• Content count

  • Joined

  • Last visited

Community Reputation

125 Neutral

About Dauntless-v2

  • Rank
  1. Try making your inner object public or protected. If that doesn't work, you might have to make it final.
  2. Codeblocks Setup with SDL

    The error message you are getting is indicating that the linker (ld.exe) can't find a library (SDLmain.dll). I am not familiar with CodeBlocks, but see if there is a way to put in search directories that contain your libraries. The other possibility is that when you built/installed libSDL, it didn't create or put SDLmain.dll in a "well known" location (for example, in linux, a well known location is usually /usr/local/lib, /usr/lib or /opt/lib)
  3. What Python Editors do you use?

    I second Editra. It's still a wee-bit buggy, but it's pretty nice nonetheless. Since it uses wxPython, if you want to get better at wxPython, you can look at the source code for ideas or examples. Another wxPython based GUI IDE is SPE, which is nice if you want to integrate your python code with Blender. And there's also Eric, which is nice if you want to integrate your code with PyQt. As you might guess, it's built on top of PyQt. Komodo Edit isn't bad, but I didn't like not having a symbol table browser. Right now, I mostly use Editra for my python coding, but Eclipse + Pyclipse isn't far behind (I like it for the bazaar integration). If I ever get seriously into my little blender project however, I'll probably switch to SPE.
  4. make your own scripting language?

    Creating a language, even a "scripring" language isn't trivial. If you don't believe me, start looking at yacc and lex, or maybe bison. Start reading up on EBNF's (Extended Backaus Naur Form). Make sure you know your automata and compiler theory. For example, know the difference between lexers and parsers. Start reading up on different grammar types (for example, LALR), and it would also behoove you to understand recursive descent parsers. At my last job, I was tasked with beginning to write a domain specific language for one of our embedded products. The only reason we went this route was because we couldn't get python to compile on our devices processor (which was actually an ADSP, not a CPU). If you can, you really want to use an existing scripting language. And it's not just because it's easier than writing a language from scratch. Also think of all the thousands of programmers that already know some language like python, (jython, ironpython), ruby, (jruby, ironruby), lua, erlang, or some other of dozens of languages out there.
  5. Python and Data Hiding

    As you mentioned, Python doesn't really enforce data-hiding in the way that you mention. Remember that Python is a dynamic language and that you can add attributes or methods dynamically on an object. class A: pass a = A() a.x = "something new" Python's sense of encapsulation means that you don't have to worry about implementation details, not whether or not an attribute has public or private access. Although python doesn't explicitly support access modifiers, you can "fake" it. A leading double underscore means that an attribute is private in the sense that if you try to access the attribute directly (via it's name), you won't be able to. Python does this by secretly name-mangling the variable with a leading underscore, the name of the class, and then the name of the variable. For example, if you have something like: class Example: def __init__(self): self.__hidden = "Don't access me directly" def get__hidden(self): return self.__hidden e = Example() e.__hidden Traceback (most recent call last): File "<input>", line 1, in <module> AttributeError: Example instance has no attribute '__hidden' e.get__hidden() "Don't access me directly" dir(e) ['_Example__hidden', '__doc__', '__init__', '__module__', 'get__hidden'] A single leading underscore is simply an indicator to other programmers that they really shouldn't be directly accessing a variable (or method). It also means that when you do a 'from mymodule import *', anything with a single leading underscore doesn't get imported. Python has a feature similar to .Net Properties (and in fact, python calls them Properties also). If you are using new-style classes (ie, inheriting directly or indirectly from object, or use __metaclass__ = type somewhere in your module), then you can use the property protocol. Basically what this means is that python will use accessor and mutator methods that you define, but they are called implicitly for you depending on the context. You can sort of implement your own protection scheme by using the magic methods of __getattr__ and __setattr__ respectively. If these magic methods are implemented, whenever someone accesses (any of) a class's attributes, then these magic methods are called. class Example: def __init__(self): self.__hidden = "Don't access me directly" def get__hidden(self): return self.__hidden def __getattr__(self, name): if name == "__hidden": print """You really shouldn't be using me directly""" else: raise AttributeError e.__hidden You really shouldn't be using me directly The larger lesson here is that python does things differently. For example, instead of having interfaces like Java or C# that are bonafide types, python uses what is called "duck-typing". If it walks like a duck and talks like a duck, it is a duck. It took me a little while to get used to dynamic programming, but now I love it. Granted, it does require a little more diligence, but I find that this enforces documentation (and docstrings are cool). And when things are dynamically typed, it actually forces you to think more polymorphically, because you may not exactly know what might get thrown in (or out). There are ways to check this at runtime through introspection, or using functions like callable (which is to be deprecated btw), but this is as ugly as using RTTI in C++.