Our rules have been updated and given
their own forum. Go and look at them! They are nice, and there may be new ones that you didn't know about! Hooray for rules! Hooray for The System! Hooray for Conforming!
Our new Indie Games subforum is now open for business in G&T. Go and check it out, you might land a code for a free game. If you're developing an indie game and want to post about it,
follow these directions. If you don't, he'll break your legs! Hahaha! Seriously though.
[Programming] Thread: Restricting masking of red pandas since 2013.
Posts
If they ask me to do OOP, I'm gonna hang myself. I wouldn't have gone back to school if I already knew all that stuff.
Okay now you make perfect sense!
Yeah, when I think "Java" in general I'm gonna think of Java developers. Poor sods.
The PhalLounge :: Chat board for Phalla discussion and Secret Santas :: PhallAX 2013
Critical Failures IRC! :: #CriticalFailures and #mafia on irc.slashnet.org
Prepare for OOP!
The PhalLounge :: Chat board for Phalla discussion and Secret Santas :: PhallAX 2013
Critical Failures IRC! :: #CriticalFailures and #mafia on irc.slashnet.org
Learn ye some OOP.
"Package the data into bundles, work with bundles using outside calls depending on what you need."
Don't worry. OOP is easy. I mean, really, really easy. I used to explain it to sales people all the time, so I have no doubt you can manage it.
Objects are responsible for data and actions. So a Circle class has a radius variable and an area method.
Objects are also responsible for protecting their data from misuse, by making it either public, private, or protected.
Inheritance is where you have a class that's a more specific "kind" than another class. So Square inherits from Rectangle inherits from Shape. (Circle also inherits from shape).
class Rectangle { private int width; private int height; public void setWidth(int w) { width = w; } public void setHeight(int h) { height = h;} public int getArea() { return width * height; } } clase Square extends Rectangle { public void setWidth(int w) { base.setWidth(w); base.setHeight(h); } public void setHeight(int h) { this.setWidth(h); } } //And you get Square.getArea() for freeInterfaces are when something isn't of a specific "kind", but you still access it in the same way
public interface RegularPolygon { int getNumberOfSides(); } public class Square implements RegularPolygon { public int getNumberOfSides() { return 4; } }Now my favorite example, vehicles!
public abstract class Vehicle { protected int velocity; protected int position; public abstract void makeUsGo(); // wheeeeeee public void tick(int t) { position += t * velocity; } } public class WheeledVehicle extends Vehicle { protected int wheelRadius; protected int wheelRPM; public void makeUsGo() { velocity += wheelRadius * wheelRPM - friction + blahmyphysicsisrustyblah; } } public interface PedalPowered { public void pedal(int rpm); } public class Bicycle extends WheeledVehicle implements PedalPowered { public void pedal(int rpm) { wheelRPM = rpm; makeUsGo(); } } public class Person { public void pedal(PedalPowered transport) { transport.pedal(this.legStrength); } }Edit: Added a very, very important comment.
I then solved the same problem with a functional language (ML I believe here).
The difference? OO was about 10 lines of code. Super simple.
The functional language required around 75 lines of code.
If OOP is wrong, I don't want to be right.
Its not that I don't want to do OOP. Its that I've never done it before, and I have terrible visions of setting the bank on fire with my terrible code.
Okay, so perhaps a touch melodramatic.
Which is backwards and will potentially hurt your development.
The biggest value in OOP is that you are breaking your design into logical pieces that transcend language specifics. When you think of the big picture and how things fit together, it is much easier to see the objects and how they should be implemented, and then you deal with your specific language and tasks.
The PhalLounge :: Chat board for Phalla discussion and Secret Santas :: PhallAX 2013
Critical Failures IRC! :: #CriticalFailures and #mafia on irc.slashnet.org
I fail to see the downside. Some banks deserve to be set on fire
In the end, OOP is just a way to think about things and compare them.
Are two things interacted with in the same way? Then they should share an interface.
Do two things work the same way? Then they should share a base class.
Any reasonable place will assume you know shit and will have to be shown everything. You won't be given responsibility until you prove you can handle it, at which point they will be super happy at any small amount.
The PhalLounge :: Chat board for Phalla discussion and Secret Santas :: PhallAX 2013
Critical Failures IRC! :: #CriticalFailures and #mafia on irc.slashnet.org
edit: it's still awesome to override methods for one particular variable though. 8->
So a simple bookstore has a couple features: books, bookshelves, cash registers, attendants, overpriced local coffee shop. Books are organized on shelves by genre and name. They have a price, which is given to the cash register at check out. Attendants perform check out, search, and organize functions on books and bookshelves. Overpriced local coffee shop makes you feel morally superior to Starbucks.
Book objects would come with ISBN, title, name, genre, prices. One method might access the text and another one select the book for purchase. If you look at inheritance, all books would have the same general information, but subtypes might include "illustrated children's books" that come with pictures as part of their type, or "books on sale" that modify price. Private information might be statistics like the number of sales or the distributor price.
Bookshelves would have genres assigned to them. I suppose they would also keep track of the books moving in and out for stocking? But would that be a method or a variable? Books would be assigned to a shelf, and the shelf would keep track of their positions.
Cash registers would use a method to total up all the book objects that are ready for purchase and remove the sold books from inventory.
Attendants would access bookshelves to sort. They would add any books that were not purchased back to the shelves. Some attendants would not be accessible to the public (stockers, the manager) and have to be petitioned through the floor attendants. Manager subtypes would have additional methods.
Overpriced local coffee shop would offer a +3 to the Smugness stat of the customer. (still more useful than cooking in WoW)
We would set up interfaces in order to call the methods that belong to each object? So you might have an interface called "ShoppingCart" that tells the bookshelf to give over the book? Another one that harasses the attendant until they cry? The interface acts as the front that the customer sees and interacts with, an intermediary between them and the moving objects.
The basic gist being that the back end of the bookstore is composed of objects poking objects, any of which can be reconfigured without changing the interface that the user sees at the front. They call "ShoppingCart" regardless of if its on bookshelf A or clearance rack B.
I mean, like almost anything, this kind of depends on a lot of things. For example, what kind of problem are you solving? Imperative languages lend themselves well to some kinds of problems, and functional languages lend themselves well to others. Then there's the issue of how one writes code; when I started messing around with F#, I was writing some very C#-like F# code, and it didn't read or run well. Then I spent some time figuring out how to restructure my thinking and write F# code like F# code instead of C#-code-in-disguise, and it read and ran much better.
I don't have a lot of practical experience with functional languages - really, just doing a bunch of Project Euler problems in F# - but there were some problems that were one-liners in F# and would have been baroque monstrosities in C#.
Like anything, you want the right tool for the job. Chopping down a tree with a screwdriver is going to be tedious, no matter how good screwdrivers are at driving screws.
With ambient light and 30 polygons, 500px square res, it runs at 0.125 frames per second!
I do have a good idea on how to use normal directions in order to implement backface culling though!
(1) Java is notoriously verbose. Some of this has to do with OOP but a lot of it also has to do with the choice of syntax and lack of language-conveniences (e.g., getters/setters as in C#).
(2) OCaml, with respect to a functional language, is also notoriously verbose. Again this has to do with some syntactic choices, but also has a lot to do with its relatively impoverished standard library (when compared to, e.g., Haskell).
While I think OO design generally over complicates programs in all the wrong ways, there are few (if any) languages that are not otherwise elegant enough to be able to "pin the problem" solely on OO.
Proponents of OOP will agree that, if the intent of a program is clear from the architecture of the source alone, without even referencing external documentation, then the code is dramatically easier to maintain and, if necessary, modify. But inheritance doesn't necessarily help toward that cause, and after all, encapsulation, delegation, and information hiding are not OOP-exclusive concepts.
There's a time and place for OOP, and in my experience, the situations in which it's the most elegant solution will be fairly obvious. Don't try to force it onto everything. That was Java's largest mistake.
A simple pseudo code (because I'm not typing out java when I don't absolutely have to) partial implementation of what you described might look like
class Book { # type name string title Author author BookShelf bookshelf string isbn BookConstrucorMethod(title, author, bookshelf, isbn) { self.title = title self.author = author self.isbn = isbn # bookshelf might be optional... maybe its not on a shelf yet self.bookshelf = bookshelf } } class Author { string firstName string lastName Books[] books #an array/list of books AuthorConstructorMethod(firstName, lastName) { self.firstName = firstName self.lastName = lastName } method writeBook(title, isbn) { book = new Book(title, self, null, isbn) self.books.append(book) return book } } class BookShelf { int shelfNumber Books[] books int maxBooks BookShelfConstructorMethod(number, maxbooks, currentBooks) { self.shelfNumber = number self.maxBooks = maxbooks self.books = currentBooks } method addBook(book) { self.books.append(book) book.bookshelf = self } method removeBook(book) { self.books.remove(book) # totally taking advantage of pseudocode here... or maybe it's a hash/dict rather than list book.bookshelf = null } }My friend used all the SSH clients in the labs as slaves for ray tracing when he was at school.
I think he rendered something in about 5 minutes.
Since I need this working sooner rather than later, I may have to just write my own one off registration system for this site, but I'm checking around just in case someone has already solved the problem.
that was like... the only reason you would use a registration module to begin with right?
The problem is that it foreign keys directly to django.contrib.auth.models.User, assumes that the User model will have a field called "username", that the username will just be a plain string, assumes there will be a field called email, a field called password, etc. User.objects.create_user() takes a username, email, and password as args and so django-registration assumes that when it calls it, in all of its forms, etc.
The most common problem here is that the custom user model ditches the username field altogether, instead you use email for the login, set CustomUserModel.USERNAME_FIELD = 'email', write a custom model manager where create_user() and create_superuser() now take email and password args rather than username, email, and password args, etc. You can also have any number of other fields which can be made required or not required. Now nothing about django-registration works. Updating django-registration to use the new model is easy, but there's a lot more work involved in making it know to use the right username field, other required fields, fields you may have renamed, etc. and even more work in getting test cases to work because you can't hard code known good values for the test cases when there's no guarantee of what is known to be valid anymore.
If I decide to keep up with it, I don't think it'll be too bad to make it work, and then for the test cases I may have default values it works with which assume django defaults and then just add a setting where you can override that stuff for your own user model if you need to. It's not undoable, just more work than I want to put into an a project which needs done soon and has a tiny budget when doing a one off project specific registration app will be quicker.
Java's largest mistake was not saying "Fuck it! We'll go all the way." and doing immutable by design.
Also, when are you pussies going to join the Clojure revolution? I'm just waiting on that first clojure job to appear... any second now. Job market will surely deliver.
Imperative programming is usually what you'll see in legacy code. It reads like a novel from top to bottom and tells a story along the way. It's intuitive to write, but is generally a pain to modify or debug since things are too interconnected. It can be done better with more structure, but still has the same issues. This is usually how people get started on programming, but it doesn't scale well and has fallen out of favor.
Functional programming is a completely different approach that starts with thinking about functions and transformations and is often used for math related fields. You want to add things, buy things, process things. In functional programming, you write your buy function then if you need to work with some other thing, you just put some code in the buy method to deal with that particular thing. There's usually a lack of state and mutability as well as passing around functions to other functions. It's really weird if you're not used to it, but makes sense for some applications.
OOP is another way of thinking. As described by everyone else, it starts with the objects or the 'things'. Those things have their own data and their own methods - they know how to look after themselves. You ask for a new book and the book knows how to create itself. This leads to dealing with objects through an interface instead of implementation. You don't care how a book gets sold, but you call a method and it happens. If selling is changing one field of book or going through 20 parent classes, it doesn't matter to you.
It's those last few features which make OOP so popular. Simple examples of OOP always seem verbose and silly because it's extra work for a simple situation. However, the bigger and more complicated the program gets, an imperative design becomes more difficult to change and debug. In an OOP design, changes are drastically easier and that's a main reason it's so popular.
I don't think it will take long for a new one to emerge that supports this.
You may want to see if the issue has been raised on the open source issue tracking... if so... make the changes!
It has been brought up. Some people even did partial patches and submitted pull requests to the developer. He closed them back in March saying that he was going to do this during PyCon 2013 sprints and making some asshole-ish remarks about people not paying attention when he said that was his plan. Unfortunately those were also in March and he didn't do it and hasn't accepted anyone else's patches. I think he will get there, he has been doing other django 1.5 stuff, just nothing related to supporting the custom user models.
What I've done for now is forked the official repo, made the obvious, simpler, non-breaking changes (which also don't fix much), etc. And then I'm writing a project specific app which is closely based on django-registration, after all, the code and process are already proven, there are just some parts that don't work. When changes I need to make are generic and don't obviously break something I'm making the same change on my django-registration fork. This way I can whip up exactly what I need without any worries about backwards compatibility, working with some other project, etc. but by the end will hopefully have made a good chunk of the changes django-registration needs while keeping it useable for other projects. If django-registration ever becomes fully 1.5 compatible I can hopefully also just swap it out with only minor changes to my project, if it makes sense to do so, such as to be using code that has more eyeballs on it.
Ultimately the point of programming paradigms is to allow you to reason as fluidly as possible. Sometimes it helps to group similar types under a broader base type. Sometimes it helps to group all functions that acts similarly, say importing data of a variety of types. In c#, if you have alot of transformations with intermediate steps, its super fun to go oops all extension methods.
If you want to check out clojure, this is the video that got me. At this point its my preferred language, and I hear there might be jobs? soon?
Sounds like all the old Rails people have moved on to Django
pity
Like say if I wanted it to stop what it's doing and notify me with a String contains the value "AFB" or something like that.
Are you just looking to do this for a particular line or anywhere in the code?
Yeah, because for a specific line all you have to do is right-click on the breakpoint and select "Breakpoint Properties"
Yeah, you can do this for a breakpoint (see this) but I don't know of any means in Eclipse to have a global watch on a break condition.
You'd have to setup the conditional on a breakpoint that is set on places where the value can change, hopefully it isn't many places and that is what you actually are trying to do?
The PhalLounge :: Chat board for Phalla discussion and Secret Santas :: PhallAX 2013
Critical Failures IRC! :: #CriticalFailures and #mafia on irc.slashnet.org