• Content count

  • Joined

  • Last visited

  1. How do you recommend to rotate the stage 90 degrees around its center?
  2. I think you would have to manually save and restore the values - or make your own save and restore functions to handle scale, rotation, etc. all at once.
  3. You can use moveTo to move the current drawing position to the start of the next arc. Like this if I have my math right: const arcAngle = Math.PI/4 const graphics = new PIXI.Graphics() graphics.lineStyle(2, 0xffd900, 1) for (let i = 0; i < 8; i++) { let angle = startAngle + i * arcAngle graphics.beginFill() // arc 1 graphics.moveTo(250 + outsideRadius * Math.cos(angle), 250 + outsideRadius * Math.sin(angle)); graphics.arc(250, 250, outsideRadius, angle, angle + arcAngle, false) // arc 2 graphics.moveTo(250 + insideRadius * Math.cos(angle + arcAngle), 250 + insideRadius * Math.sin(angle + arcAngle)); graphics.arc(250, 250, insideRadius, angle + arcAngle, angle, true) graphics.endFill() }
  4. Yeah that was bad example relative to what you're looking for, since it's for providing typescript definitions and doesn't show how a typescript project would be structured, it was more for showing the basic usage in the test file. Maybe someone else has a good example.
  5. > Out of interest, if you wanted to include an http library named Request and a state management helper utility library called Request, both expecting to stick to a global Request namespace, how would you handle that? Drop one? Seems a shame. I guess I would add the first library to my project and tell the IDE to refactor the namespace's name from Request to HttpRequest. Then I'd add the second library and refactor from Request to StateRequest. Dropping one of the libraries wouldn't be necessary but I agree it's a bad situation to have to do a refactor for each conflicting library (and again when the library updates). Maybe there's a better way to handle it, if not the namespace feature should evolve to handle this better. Or module could evolve to allow default naming.. >> Yes naming the same module the exact same way over and over is a chore I would rather do w/out. If it's usually named after the library to prevent collisions anyway, why not allow that to be the default naming behavior? > Because its enforcing and can not be undone, not a great decision for an ecosystem. I was just wondering why not allow defaults since the module is usually named the same way over and over again. E.G., if you could omit name when importing a module to let the alias be created with the default name - as an option, not to enforce anything. And as a concept/goal, not as module vs namespace. > If you like to use this in your own projects then more power to you, similarly if you want to use it for libraries you consume then cool. Fair enough, and really I'm just sharing what I perceive to be one benefit of using namespace vs module, not really recommending namespace over module nor saying that anyone should use it instead, per se. If anything I would argue in favor of supporting default naming and allowing to name once, not for using module or namespace.
  6. Was reminded that each file should start out with a /// reference line for each file it depends on. I'd been using using namespace w/out these for awhile because my IDE didn't seem to need them (e.g. auto-complete, error-checking, etc. still worked fine without them), but I guess my projects weren't big enough to need them, in terms of the volume of original code with missing references. /// <reference path="boilerplate/animals.ts" /> /// <reference path="boilerplate/vehicles.ts" /> let jaguarAnimal = new Boilerplate.Animals.Jaguar(); let jaguarVehicle = new Boilerplate.Vehicles.Jaguar();
  7. Yes naming the same module the exact same way over and over is a chore I would rather do w/out. If it's usually named after the library to prevent collisions anyway, why not allow that to be the default naming behavior? And yes for projects with multiple developers default naming can help ensure that everyone's using the exact same names. Really I'm a proponent of name-once-ability, not of typescript namespace specifically. If could optionally omit the name when importing module and use default, that would be an improvement to take IMO. I don't see what's so dreadful about being able to use default names;)
  8. The goal I was suggesting is to remove the redundancy of importing and uniquely-naming-after-the-library the same way over and over again, not to reduce choice. Users still have the choice to alias and pick name they want, but also have the option to skip the imports and just use the names established by libraries. As long as the per library namespaces are kept unique, avoiding name conflicts between them is a done deal and there's no need to import nor even think about naming. But using two libraries which happen to add to the same top-level namespace, yeah that should be easier to handle. There are options (like refactoring one library's top-level namespace), but yeah no good options I guess, at least not yet..
  9. "Because the consumer of a module decides what name to assign it, there’s no need to proactively wrap up the exported symbols in a namespace." This could be rewritten as: "Because the exported symbols are proactively wrapped up in a namespace, there's no need for the consumer to decide what name to assign." As for the example, it's an example of improper usage so of course it will be confusing and annoying;) Instead of importing as 'shapes' and using 'shapes.Shapes.Triangle' to refer to the the Triangle class, which is ridiculous, namespaces can be used to allow the consumers to refer to the class as 'Shapes.Triangle' without the need to import nor name: // shapes.ts namespace Shapes { export class Triangle { /* ... */ } export class Square { /* ... */ } } // consumer.ts let t = new Shapes.Triangle();
  10. javascript

    You could set window.location.href to the new page like this: if (something) { window.location.href = "page1.html"; } else { window.location.href = "page2.html"; }
  11. I think a big selling point is that the burden and hassle of avoiding name conflicts is removed from the user and instead handled by the library. So the library (or project part) is more self sufficient. Even if it only takes a tiny bit of thought and work to import and uniquely name (alias) each class, it still adds up and is one more thing to worry about/do over and over again. So instead of making each user do this for each usage, we can handle the naming/organizing once for all usages.
  12. If each library uses its own unique namespace then name conflicts between libraries are avoided. And for a large project spit into parts, if each part uses a unique namespace then name conflicts between these parts are avoided. Like in my example the namespace Boilerplate is added to the global namespace and then more namespaces are added to the Boilerplate namespace (to organize the classes and keep their names from conflicting). Boilerplate is the only one added to the global namespace, so as long as no other code adds to the Boilerplate namespace, naming collisions with the Boilerplate library are avoided. Keeping the "top-level" namespaces (those that are added to the global namespace, like Boilerplate in my example) unique is relatively trivial, especially if each is named after the library or project/part.
  13. No, you don't need to import. You can see in the main.ts file that I just start using the classes right away. In index.html file there would be a script tag for each of the above three files - or you could concat all of the files that add to the Boilerplate namespace for easier usability. Edit: you don't need to import but you can if you want shorter names for example: import Jaguar = Boilerplate.Vehicles.Jaguar; let myCar = new Jaguar();
  14. Yes any currentStep param greater than or equal to 215 (the steps param) would be color2 I think, since going past color2 would be extrapolation, not interpolation (actually I'm not 100% sure that it clips at the bounds instead of extrapolating past them, but would expect to honor bounds and stay between color1 and color2). From the docs: "If the interpolation will take 100 steps, a currentStep value of 50 would be half-way between the two."
  15. You might still want to compensate for when FPS deviates from 60 You can pass delta (the parameter to animate function) to your move function and use 'var speed = delta * this._moveTo.speed;' to compute the FPS-adjusted speed.