[h2ooooooo]

h2ooooooo posted:

Working on a PHP framework

Here's the errors/debug messages it produces:



Of course complete with a stack trace when you click:

To the guys who rated me disagree - please come with your input. What would you suppose that I do instead? I've been going over this in my head a million times, and static classes was the closest I got to a global solution without the need for regular classes and or creating/getting instances first.

Rate your favourite one:

Current:

<?php
	namespace pTas;
	
	require_once('ptas.php');
	
	Debug::SetDebugLevel(DebugLevel::VERBOSE);
	
	Core::IncludeModuleOnce('Curl');
	Core::IncludeModuleOnce('Crap');
	Curl::CreateInstance('derp', true);
	Curl::CreateInstance('sherp');
	Curl::SetInstance('sherp');
	Curl::DeleteInstance('sherp');
	Curl::SetInstance('sherp');
	
	Debug::Error('Here\'s an "Error" debug message');
	Debug::Warning('Here\'s a "Warning" debug message');
	Debug::Info('Here\'s an "Info" debug message');
	Debug::Debug('Here\'s a "Debug" debug message');
	Debug::Verbose('Here\'s a "Verbose" debug message');
?>

Singleton: (even though it might be slower in a big environment)

<?php
	namespace pTas;
	
	require_once('ptas.php');
	
	$debugInstance = Debug::GetInstance();
	$debugInstance->SetDebugLevel(DebugLevel::VERBOSE);
	
	$coreInstance = Core::GetInstance();
	$coreInstance->IncludeModuleOnce('Curl');
	$coreInstance->IncludeModuleOnce('Crap');
	
	$curlInstance = Curl::GetInstance();
	$curlInstance->CreateInstance('derp', true);
	$curlInstance->CreateInstance('sherp');
	$curlInstance->SetInstance('sherp');
	$curlInstance->DeleteInstance('sherp');
	$curlInstance->SetInstance('sherp');
	
	$debugInstance->Error('Here\'s an "Error" debug message');
	$debugInstance->Warning('Here\'s a "Warning" debug message');
	$debugInstance->Info('Here\'s an "Info" debug message');
	$debugInstance->Debug('Here\'s a "Debug" debug message');
	$debugInstance->Verbose('Here\'s a "Verbose" debug message');
?>

Referencing by core:

<?php
	namespace pTas;
	
	require_once('ptas.php');
	
	$core = Core::GetInstance();
	
	$core->Debug->SetDebugLevel(DebugLevel::VERBOSE);
	
	$core->IncludeModuleOnce('Curl');
	$core->IncludeModuleOnce('Crap');
	$core->Curl->CreateInstance('derp', true);
	$core->Curl->CreateInstance('sherp');
	$core->Curl->SetInstance('sherp');
	$core->Curl->DeleteInstance('sherp');
	$core->Curl->SetInstance('sherp');
	
	$core->Debug->Error('Here\'s an "Error" debug message');
	$core->Debug->Warning('Here\'s a "Warning" debug message');
	$core->Debug->Info('Here\'s an "Info" debug message');
	$core->Debug->Debug('Here\'s a "Debug" debug message');
	$core->Debug->Verbose('Here\'s a "Verbose" debug message');
?>

Global variables #1 (yuck):

<?php
	namespace pTas;
	
	require_once('ptas.php');
	
	$GLOBALS["core"]->Debug->SetDebugLevel(DebugLevel::VERBOSE);
	
	$GLOBALS["core"]->IncludeModuleOnce('Curl');
	$GLOBALS["core"]->IncludeModuleOnce('Crap');
	$GLOBALS["core"]->Curl->CreateInstance('derp', true);
	$GLOBALS["core"]->Curl->CreateInstance('sherp');
	$GLOBALS["core"]->Curl->SetInstance('sherp');
	$GLOBALS["core"]->Curl->DeleteInstance('sherp');
	$GLOBALS["core"]->Curl->SetInstance('sherp');
	
	$GLOBALS["core"]->Debug->Error('Here\'s an "Error" debug message');
	$GLOBALS["core"]->Debug->Warning('Here\'s a "Warning" debug message');
	$GLOBALS["core"]->Debug->Info('Here\'s an "Info" debug message');
	$GLOBALS["core"]->Debug->Debug('Here\'s a "Debug" debug message');
	$GLOBALS["core"]->Debug->Verbose('Here\'s a "Verbose" debug message');
?>

Global variables #2 (yuck again):

<?php
	namespace pTas;
	
	require_once('ptas.php');
	
	$GLOBALS["debug"]->SetDebugLevel(DebugLevel::VERBOSE);
	
	$GLOBALS["core"]->IncludeModuleOnce('Curl');
	$GLOBALS["core"]->IncludeModuleOnce('Crap');
	$GLOBALS["curl"]->CreateInstance('derp', true);
	$GLOBALS["curl"]->CreateInstance('sherp');
	$GLOBALS["curl"]->SetInstance('sherp');
	$GLOBALS["curl"]->DeleteInstance('sherp');
	$GLOBALS["curl"]->SetInstance('sherp');
	
	$GLOBALS["debug"]->Error('Here\'s an "Error" debug message');
	$GLOBALS["debug"]->Warning('Here\'s a "Warning" debug message');
	$GLOBALS["debug"]->Info('Here\'s an "Info" debug message');
	$GLOBALS["debug"]->Debug('Here\'s a "Debug" debug message');
	$GLOBALS["debug"]->Verbose('Here\'s a "Verbose" debug message');
?>

Regular old (possible re)creating of classes:

<?php
	namespace pTas;
	
	require_once('ptas.php');
	
	$debugClass = new Debug();
	$debugClass->SetDebugLevel(DebugLevel::VERBOSE);
	
	$coreClass->IncludeModuleOnce('Curl');
	$coreClass->IncludeModuleOnce('Crap');
	
	$curlClass = new Curl();
	$curlClass->CreateInstance('derp', true);
	$curlClass->CreateInstance('sherp');
	$curlClass->SetInstance('sherp');
	$curlClass->DeleteInstance('sherp');
	$curlClass->SetInstance('sherp');
	
	$debugClass->Error('Here\'s an "Error" debug message');
	$debugClass->Warning('Here\'s a "Warning" debug message');
	$debugClass->Info('Here\'s an "Info" debug message');
	$debugClass->Debug('Here\'s a "Debug" debug message');
	$debugClass->Verbose('Here\'s a "Verbose" debug message');
?>

[Jelly]

Why do you need to log so much shit anyway?

[h2ooooooo]

Jelly posted:

Why do you need to log so much shit anyway?

I don't, it was to test the module. Hence the test message, and the line "SetDebugLevel(DebugLevel::VERBOSE)". Default is simply ERROR and WARNING, and therefore wouldn't output (not log), all this "shit".

Edited:

StinkyJoe posted:

My god...so many static calls...that looks like dependency hell - what if you want to inject your own class for something like Debug?

Pro-tip: 99.99% of the times you think a static method is the right thing to do, you'll be wrong.

Do you mean using the debug class inside of your own class? Very simple. Just call Debug (if in pTas namespace) or pTas\Debug. The reason for the staticness is global access without the use of singletons. The core automatically imports stuff itself when you call IncludeModule or IncludeModuleOnce, and once it's included, it ignores it if you try (for some odd reason) to include it again - hence working the same way as singletons, as there's no need for additional overhead by creating a class multiple times.

[adamjon858]

rulssi posted:

This is something I worked on few years back, thought about finishing it and translating it to English.

Those colors.....please please tone them down. Way too obnoxious.

Edited:

h2ooooooo posted:

To the guys who rated me disagree - please come with your input. What would you suppose that I do instead? I've been going over this in my head a million times, and static classes was the closest I got to a global solution without the need for regular classes and or creating/getting instances first.

Combination of Singleton and Core. Also, who's telling you that their inefficient? They're only inefficient if you're building massive massive architecture's without a starting framework. And usually there's going to be another weak link before you get to that point.

For any framework, Singletons are all but necessary to work effectively and efficiently.

Edited:

TerabyteS_ posted:

Why do you use such strong perspective distortions on the text? It'd look better without imo.

Huh? That's a real life picture. No photoshopping.

[TerabyteS_]

adamjon858 posted:

Huh? That's a real life picture. No photoshopping.

The text is shopped on.

[h2ooooooo]

adamjon858 posted:

Combination of Singleton and Core. Also, who's telling you that their inefficient? They're only inefficient if you're building massive massive architecture's without a starting framework. And usually there's going to be another weak link before you get to that point.

For any framework, Singletons are all but necessary to work effectively and efficiently.

For every new function you start, if you want to reference the core or any module in it, you'll have to call Core::GetInstance() once again, and assign the reference to a variable - this seems like a waste of calls (if done in for example 100 functions spread across your classes/pages) compared to simply always being able to call the static function, which was the main reason I did it the other way to start with.

Edited:

Take the following example:

<?php
	function a() {
		$core = Core::GetInstance();
		$core->Debug->Debug("inside of function A");
		b();
	}
	function b() {
		$core = Core::GetInstance();
		$core->Debug->Debug("inside of function B");
		for ($i = 0; $i < 100; $i++) {
			c($i);
		}
	}
	function c($i) {
		$core = Core::GetInstance();
		$core->Debug->Debug("inside of function C with count " . $i);
	}
?>

That's 102 calls to GetInstance.

Edited:

Compared to the following:

<?php
	function a() {
		Debug::Debug("inside of function A");
		b();
	}
	function b() {
		Debug::Debug("inside of function B");
		for ($i = 0; $i < 100; $i++) {
			c($i);
		}
	}
	function c($i) {
		Debug::Debug("inside of function C with count " . $i);
	}
?>

But again, I don't know what has the most overhead. My guess would be static methods, but I'm unsure.

[StinkyJoe]

Your idea of a singleton is wrong, really - there's absolutely NOTHING wrong with having your application create an instance, and using that instance only, that's NOT what a singleton is.

class Application
{
    private $http_handler;
    public function start()
    {
        $this->http_handler = new \http\Handler;
    }

    public function http()
    {
        return $this->http_handler;
    }
}

$application = new Application;
$application->start();
$application->http()->end(200);

That is NOT a singleton, and allows you to manage your dependencies in a sane and flexible manner (there's no ties to any particular class through static calls, there's no global state, etc).

Stop worrying about performance so much, you're basing yourself on near-voodoo concepts that are at best misguided, and worst completely incorrect.

[h2ooooooo]

StinkyJoe posted:

Your idea of a singleton is wrong, really - there's absolutely NOTHING wrong with having your application create an instance, and using that instance only, that's NOT what a singleton is.

class Application
{
    private $http_handler;
    public function start()
    {
        $this->http_handler = new \http\Handler;
    }

    public function http()
    {
        return $this->http_handler;
    }
}

$application = new Application;
$application->start();
$application->http()->end(200);

That is NOT a singleton, and allows you to manage your dependencies in a sane and flexible manner (there's no ties to any particular class through static calls, there's no global state, etc).

Stop worrying about performance so much, you're basing yourself on near-voodoo concepts that are at best misguided, and worst completely incorrect.

How would you then rewrite the code in my previous post using your method?

Edited:

The only way that I could see that it would possibly work (without the use of global variables) is this:

<?php
	class Application
	{
		private $http_handler;
		public function start()
		{
			$this->http_handler = new \http\Handler;
		}
	 
		public function http()
		{
			return $this->http_handler;
		}
	}
	function a() {
		$application = new Application;
		$application->start();
		$application->test()->blah("asd");
		b();
	}
	function b() {
		$application = new Application;
		$application->start();
		$application->test()->blah("asd #2");
		for ($i = 0; $i < 100; $i++) {
			c($i);
		}
	}
	function c($i) {
		$application = new Application;
		$application->start();
		$application->test()->blah("asd #3 - " $i);
	}
?>

Unless you want to make a new application class for every single other class you have?

Edited:

If you have any other idea as to how it could be made, feel free to tell me. I'm always up for possibly learning something new. :)

[StinkyJoe]

Going to try and type this out on a smartphone, pardon any mistake...you're not understanding how object orientation works...your application is a "thing", it has its dependencies, its own classes and execution lifetime...you can have, theoretically speaking, multiple active applications at any moment, without any sort of globally shared state or knowledge of their surroundings, and that's great! Hence, and to try and apply this to your example, each application has its own debugger instance, and methods for working with this instance - maybe you pass the application object around, maybe you pass the debugger directly, it really depends on what you're doing - ...where was I...it's easy to lose my train of thought at 2 wpm...anyway...global shared state bad, static methods bad, hard dependencies bad, high cohesion and accountability good!

With this, I'm going to sleep, I'l answer any questions tomorrow, tata!

[Ac!dL3ak]

bluh

class Core {

private $classes = array();

static public $instance;

function __construct()
{

if( empty( $this->instance ) )
{

self::$instance =& $this;

}
else
// throw some error

}

function extend( $name, &$class ){

$this->classes[ $classes ] =& $class;

}

function _get( $name )
{

if( !empty( $this->classes[ $name ] ) )
{

return $this->classes[ $name ];

}
else return false;

}

static function instance()
{

return self::$instance;

}

}

function get_instance()
{
return Core::instance();
}

and then have a class meant for extending

class extend {

function _get( $name )
{
return get_instance()->{ $name };
}

}

and then extend the core

class debug {

function log( $value, $something )
{

echo $value, $something;

}

}

get_instance()->extend( "debug", new debug );

class App extends extend {

function __construct()
{
$this->debug->log( "something", "something" );
}

}

that's how i'd do it but it could be a bit shitty

[acpm]

There are architectural purposes for using a singleton. Print/log debugging by itself is not one of them.

[h2ooooooo]

amcfaggot posted:

There are architectural purposes for using a singleton. Print/log debugging by itself is not one of them.

Once again, the print/logging was just an example. But as a person who just (thought that he) learnt what a singleton is just a few days ago, could you explain it to me, instead of just saying "this is not the way to do it", considering I obviously missed the point of it? It's really not very helpful.

Edited:

Ac!dl3ak, that method, while appreciated written out, is essentially no different from my "Referencing by core" example, except that you add methods differently, and use a global function that calls the static function.

[swift and shift]

singletons are rarely the right thing to do

Edited:

if you feel you have a valid use case for a singleton, you need to seriously think about it

Edited:

For example, there are a few singletons I've implemented in Twostroke and none of them store any state.

They're just singletons for the sake of memory efficiency:



Edited:

If you have a singleton that keeps state (whether directly or indirectly through I/O), you're probably doing it wrong.

[h2ooooooo]

So your suggestion in the top post on this page that global variables are the way to go, wasn't a joke? AFAIC, global variables are bad practise, or have I got that wrong?

Edited:

By the way, thanks for the explanation. :)

[swift and shift]

h2ooooooo posted:

AFAIC, global variables are bad practise, or have I got that wrong?

global variables are usually bad

PHP is different because the entire thing is reloaded every time someone makes a request so there's not much state to encapsulate or any of that proper bullshit.

It's not like a long running application framework where you have a request and response object that encapsulate individual client requests and shit. In PHP there's the request where you're serving up a response to the client.

[BrettJay]

spidersdesign posted:

Yes the portfolio site is shitty. I have made a few sites for example http://www.ringwoodtfsr.co.uk/
- they just aren't listed there, I don't maintain my portfolio site as I no longer accept web design jobs. I would just take it down but a few posts get a reasonable amount of traffic so I have left it.

Like every other 'design' you've ever made it all just borrows from designers much more talented than yourself. Seriously, I think Orman Clarke's handiwork has appeared in almost all your sites to date.

[swift and shift]

snip

[StinkyJoe]

swift and shift posted:

should i buy yaff.in or yiff.asia or something else?

If you don't buy yaff.in, I will!

[swift and shift]

StinkyJoe posted:

If you don't buy yaff.in, I will!

you can contribute it to our little project

[adamjon858]

To be fair, I think you all are just way over thinking this issue and it's getting ridiculous.

I use singletons for 3 things. Template engine, database connection, and my auth/session handler.

These are things you are probably going to want persistent across most of the classes you use...although template engine could be debated and I use Smarty (prepares for OMG INEFFICIENT shitstorm). Sure you can find a way to keep passing this stuff between classes without singletons, but once you start dealing with really large projects it gets quite crazy.

I have a few sites that can handle 1000 simultaneous visitors on an Intel Atom server.... For me, I've found that using Nginx instead of Apache and making sure I optimize my queries and my overall data layout has way more effect than worrying about singletons.

Furthermore, here's how I usually handle singletons:

<?php

class wtfshit extends modbase {

private $db;
private $auth;
private $smarty;

function __construct(){
$db = PDO::get_instance();
$auth = auth::get_instance();
$smarty = smartyex::get_instance();
$this->permission_add('home','public');
}

function home(){
$news=$this->db->get_rows('SELECT * from news');
$this->smarty->assign('news',$news);
return $this->smarty->fetch('home.html');
}

}

?>

Edited:

swift and shift posted:

If you have a singleton that keeps state (whether directly or indirectly through I/O), you're probably doing it wrong.

I entirely disagree. Once you start having 4-5 different modules and multiple API libraries that all need to interact with a single database connection....singletons are the way to go. You can make it work without singletons but they exist for a reason. There are lots of times where people misuse them (like I think his original post demonstrates), but they do have a purpose. Sometimes you need persistence even if it is just for the mere milliseconds of a single page load. In PHP, It's practically the core of getting the parts of MVC to work with each other effectively. I wouldn't say this about other languages, I'm just saying that for PHP it's a good choice.

For Python, I like using Twisted and having everything persistent :D. Having database objects cached in the memory for a minute or so unless they are used again is so much better then having to reload everything for each instance and connection.

[StinkyJoe]

We can afford to be purely academical here, and the truth is, I can't think of a single situation where a singleton is good design...everyone's made good points, and once you're out in the real world you'll be judged by your choices, I'd just rather make an effort to teach good practices as much as possible (even if at times it seems obsessive) while we can.

In closing, h2oooooo's implementation is very wrong®, I repectfully disagree with (but understand) adam's implementation, and i'd like yo have it recorded that I wrote this while doing a poop, and that my posterior is now a tad sore.

[TerabyteS_]

StinkyJoe posted:

We can afford to be purely academical here, and the truth is, I can't think of a single situation where a singleton is good design...everyone's made good points, and once you're out in the real world you'll be judged by your choices, I'd just rather make an effort to teach good practices as much as possible (even if at times it seems obsessive) while we can.

In closing, h2oooooo's implementation is very wrong®, I repectfully disagree with (but understand) adam's implementation, and i'd like yo have it recorded that I wrote this while doing a poop, and that my posterior is now a tad sore.

Next thread's tagline is going to be "StinkyJoe posts from the loo"

[adamjon858]

StinkyJoe posted:

I'd just rather make an effort to teach good practices as much as possible (even if at times it seems obsessive)

Good practices. Using PHP. wut? We all need to make sacrifices somewhere :D

I repectfully disagree with (but understand) adam's implementation, and i'd like yo have it recorded that I wrote this while doing a poop, and that my posterior is now a tad sore.

What's wrong with mine? And if you had a site with 80 different classes, not all of which are used simultaneously...that'd be awful, but half of which needed database interaction, how would you pass the database connection to every single one? (RUN RUN-ON SENTENCE RUN)

I've been working on my PHP framework for 5 years. And I've done hundreds of tests and built 150+ commercial websites with it. I just recently abandoned PHP entirely in favor of Python, but I feel like I've made very informed decisions in the creation of my PHP framework.

[andersonmat]

I've been working on revising my sub-navigation menus. Opinions?

[StinkyJoe]

adamjon858 posted:

Good practices. Using PHP. wut?

Well, that's part of the problem with PHP in general.

adamjon858 posted:

I've been working on my PHP framework for 5 years. And I've done hundreds of tests and built 150+ commercial websites with it. I just recently abandoned PHP entirely in favor of Python, but I feel like I've made very informed decisions in the creation of my PHP framework.

I have no doubts about the palpable qualities of your framework, but I've seen snippets you posted here (please do correct me if I'm mistaken), and it was usually quite far from what I'd call ideal or well designed - no doubt functional, and you may say that at the end of the day it's the base line final product that matters most (and I'll be hard pressed to disagree), but like I said, here we can afford to judge from our golden (or in my case, porcelain) thrones, far from the development trenches.

To answer your question:

adamjon858 posted:

And if you had a site with 80 different classes, not all of which are used simultaneously...that'd be awful, but half of which needed database interaction, how would you pass the database connection to every single one?

I'd start by asking why in the hell 40 of your (hypothetical) classes need access to a database connection? Separation of concerns dictates that I wouldn't have more than one instance per connection managing the database interfacing, and turning that into usable data structures - which would in turn only be passed along where needed. Don't design super methods, delegate tasks and only provide the minimum access/data/components required to perform those tasks.

Did I ever mention I love discussing this sort of shit?

(I hope I don't come off as bashing you or your framework, adam, these discussions can quickly delve into ridiculous levels of pedanticness).

[acpm]

StinkyJoe posted:

We can afford to be purely academical here, and the truth is, I can't think of a single situation where a singleton is good design

Literally any design where you need a single instance of something, which entails an initialization process, for any given lifetime? Adam's example is a perfect one.

Singletons are more important outside of web development where systems are required by design to have a single instance of something which requires initialization. Web developers have what, databases? Even that, if you want to be messy doesn't require one-time instantiation. Developers working on desktop applications have to deal with rendering states, hardware interaction, low-level networking, low-level filesystem management, and the list goes on for where singletons are needed.

In web development, such patterns aren't as common or necessary but rather are more of a functionality convenience and plain good practice.

Edited:

You guys are complaining about issues which are largely relevant in performance situations, not necessity ones.

[StinkyJoe]

amcfaggot posted:

Literally any design where you need a single instance of something, which entails an initialization process, for any given lifetime? Adam's example is a perfect one.

Singletons are more important outside of web development where systems are required by design to have a single instance of something which requires initialization. Web developers have what, databases? Even that, if you want to be messy doesn't require one-time instantiation. Developers working on desktop applications have to deal with rendering states, hardware interaction, low-level networking, low-level filesystem management, and the list goes on for where singletons are needed.

In web development, such patterns aren't as common or necessary but rather are more of a functionality convenience and plain good practice.

Edited:

You guys are complaining about issues which are largely relevant in performance situations, not necessity ones.

Nobody's complaining, we're having an interesting discussion, sheesh!

Let me start by pointing out that "using an instance of x" does not equal a singleton.

This is a singleton(ish) (php-pseudo-code):

class Foo
    __construct()
        if( static::$instance )
            throw Exception "cannot instantiate"

    static getInstance()
        if( !static::$instance )
            static::$instance = new __CLASS__
        return static::$instance

This is not:

class Application
    start()
        $this->http = new Http;


$app = new Application
$app->http->end(200)

There's hardly a good reason to hold global state in an object-oriented application - maybe there's some reasons, but I've yet to come across a valid use for it. Swifturb made a good point about how the life-cycle of a PHP script reduces the concerns of global state, but it's still bad practice (golden throne, etc).

[acpm]

It seems to me more like you're referring to a single instance of something as being a single object and not a singleton, which is in part what a singleton is, a sole instance.

[h2ooooooo]

StinkyJoe posted:

Well, that's part of the problem with PHP in general.



I have no doubts about the palpable qualities of your framework, but I've seen snippets you posted here (please do correct me if I'm mistaken), and it was usually quite far from what I'd call ideal or well designed - no doubt functional, and you may say that at the end of the day it's the base line final product that matters most (and I'll be hard pressed to disagree), but like I said, here we can afford to judge from our golden (or in my case, porcelain) thrones, far from the development trenches.

To answer your question:



I'd start by asking why in the hell 40 of your (hypothetical) classes need access to a database connection? Separation of concerns dictates that I wouldn't have more than one instance per connection managing the database interfacing, and turning that into usable data structures - which would in turn only be passed along where needed. Don't design super methods, delegate tasks and only provide the minimum access/data/components required to perform those tasks.

Did I ever mention I love discussing this sort of shit?

(I hope I don't come off as bashing you or your framework, adam, these discussions can quickly delve into ridiculous levels of pedanticness).

Imagine a site that has classes spread across various things,

Boards,
Profile,
Login,
Purchases,
Ranking,
etc.

It's easily done like that in a regular large site developement. Creating a new class every time would be absoloutly ridiculous, both in a logical and in a performance sense.

[TerabyteS_]

andersonmat posted:

I've been working on revising my sub-navigation menus. Opinions?

That's lovely, but if I were you I'd change a few things (take this as an entirely personal opinion):



The text-shadow and bright color look a little out of place here. Instead, I'd tone down the color (just a slight bit) and set the font-weight to bold on all buttons and badges. Also, if on the unread badge you've used a gradient, I'd suggest you don't: it makes it look like a button when in fact it isn't. It might also become even more badge-like if you removed the darker 1px border and placed it alongside the title of the message instead of having it on the right side.



These buttons look incredibly nice but at the same time they look as if they're depressed (not psychologically ). Try to push the box-shadow a downwards bit and either have them like that or add another white box-shadow on top to show an highlight as if light was coming from the top.

Also, the logo should play an important part in such a design:



right now it looks a little small. I'd suggest that you use the nice amount of space you have on that bar and try to make the logo a little bigger and maybe use a bold font to give it more importance.

[StinkyJoe]

h2ooooooo posted:

Imagine a site that has classes spread across various things,

Boards,
Profile,
Login,
Purchases,
Ranking,
etc.

It's easily done like that in a regular large site developement. Creating a new class every time would be absoloutly ridiculous, both in a logical and in a performance sense.

amcfaggot posted:

It seems to me more like you're referring to a single instance of something as being a single object and not a singleton, which is in part what a singleton is, a sole instance.

No, that's not a singleton, and you don't create a new class every time you need to access the database - your application controller has a database connection (an instance, or an instance of a controller that knows how to use the connection instance), and it keeps it for itself, without introducing global state - theoretically speaking you should be able to instantiate an infinite amount of application controller instances without side effects (besides maybe your server catching fire), that's my whole point.

I know about large site development, every day I work on various different applications, most with at least a couple hundred components.

[acpm]

A singleton is a sole instance. Singleton as in singleton. You're arguing more about whether or not I'm using new once and retrieving the same memory over and over from a method vs if I'm using a single object defined outside of the class definition itself more than the actual usage of a singleton.

Edited:

That is to say you're talking more about the concept of something along the likes of an initialization on demand holder.

Edited:

In fact, all of your examples of singletons are lazy initializations.

[StinkyJoe]

amcfaggot posted:

A singleton is a sole instance. Singleton as in singleton. You're arguing more about whether or not I'm using new once and retrieving the same memory over and over from a method vs if I'm using a single object defined outside of the class definition itself more than the actual usage of a singleton.

I'm arguing about the difference between using a singleton (which introduces global state and constraints) and instantiating a class within a component and sharing it downstream (which is the right thing to do).

Here's an example: you have an application, it needs a database connection, you think to yourself "Great! Time to apply those great concepts I learned from PHPMaster.com! I'll use a singleton - single means it's cheaper and will make my PHP fast!"

- - two hours of singleton-related development later --

"Great! Now I have my own ConnectionClass, and I can use its static ::getInstance() method to have access to its methods without creating a new instance every time!

Uhmm, my application would really benefit from this new component, ComponentX! Let's see the requirements...right, it needs to connect to a another database...oh crap, my ConnectionClass nonsense is useless now, since I can't get a new connection instance for another database link :( "

:(

To pre-emptively answer questions:

Q. But duh, it's not like I'll EVER need more than a single database connection in my application!
A. Great! It's still poor design, but whatever works for you!

Q. But duh! I can just have ConnectionClass2, which extends from ConnectionClass but holds a link to database 2
A. Ouch

Q. But duh! StinkyJoe, why are you being so pedantic about this?
A. Golden throne, good practices, do as I say not as I do, yadda yadda yadda.

[acpm]

If you're abstracting your database connections in a way that only allows a single database connection perhaps you should rethink why you need to use a singleton and ask yourself if you've written a proper singleton in the first place.

[StinkyJoe]

amcfaggot posted:

If you're abstracting your database connections in a way that only allows a single database connection perhaps you should rethink why you need to use a singleton and ask yourself if you've written a proper singleton in the first place.

If you have a database connection class that does not map directly to a single lower-level connection, I don't think you really understand object-orientation at all, and question what the hell is the class's purpose after all.

Edited:

Maybe if you have a DatabaseConnectionAggregator class or something, but even I think that's fucked up.

[acpm]

That's about as valid as saying if you have a filesystem class which doesn't map directly to a single file that the class doesn't have a legitimate purpose.

[Catdaemon]

StinkyJoe posted:

If you have a database connection class that does not map directly to a single lower-level connection, I don't think you really understand object-orientation at all, and question what the hell is the class's purpose after all.

can you write more words because this is a strange thing to say

[StinkyJoe]

amcfaggot posted:

That's about as valid as saying if you have a filesystem class which doesn't map directly to a single file that the class doesn't have a legitimate purpose.

No...that's like saying if you have a File class instance that maps to ALL files in the system you need to learn that you don't use OO constructs to emulate namespacing, or like saying if you have a FileSystem class that you can only use once for a single file per execution, you need to learn what object-orientation means.

Edited:

Catdaemon posted:

can you write more words because this is a strange thing to say

Can I just paste straight from lipsum.net or...? Seriously now, read what I just said above, it should clear it up.

[acpm]

I think we're blurring the line of overly-pedantic discussion. We all raised valid points. Let's agree to disagree.

[andersonmat]

TerabyteS_ posted:

That's lovely, but if I were you I'd change a few things (take this as an entirely personal opinion):



The text-shadow and bright color look a little out of place here. Instead, I'd tone down the color (just a slight bit) and set the font-weight to bold on all buttons and badges. Also, if on the unread badge you've used a gradient, I'd suggest you don't: it makes it look like a button when in fact it isn't. It might also become even more badge-like if you removed the darker 1px border and placed it alongside the title of the message instead of having it on the right side.

Thanks, I'll take a look later and tone down the intensity of the colour and look into making it fit in more appropriately. As for the notification bubble for unread messages, I agree, it definitely looks like a button and I should make it "flat".

TerabyteS_ posted:

These buttons look incredibly nice but at the same time they look as if they're depressed (not psychologically ). Try to push the box-shadow a downwards bit and either have them like that or add another white box-shadow on top to show an highlight as if light was coming from the top.

Definitely agree! It'd be a good :active or :hover state, but not how they are currently. I'll remove the inset gradient and see where that puts me.

TerabyteS_ posted:

Also, the logo should play an important part in such a design:



right now it looks a little small. I'd suggest that you use the nice amount of space you have on that bar and try to make the logo a little bigger and maybe use a bold font to give it more importance.

Roger that. I also have a real logo in the works that'll get put up there.

I appreciate the feedback! :)